Apply 1.21-ko.2 enhancement to 1.22-ko.3
This commit is contained in:
Seokho Son
parent
b81dcba911
commit
7373ffe1fd
|
|
@ -51,7 +51,7 @@ weight: 10
|
|||
```
|
||||
|
||||
쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는
|
||||
kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어있는지 확인한다.
|
||||
kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어 있는지 확인한다.
|
||||
노드가 정상이면(예를 들어 필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다.
|
||||
그렇지 않으면, 해당 노드는 정상이 될 때까지 모든 클러스터 활동에
|
||||
대해 무시된다.
|
||||
|
|
@ -146,7 +146,7 @@ kubectl cordon $NODENAME
|
|||
kubectl describe node <insert-node-name-here>
|
||||
```
|
||||
|
||||
출력되는 각 섹션은 아래에 설명되어있다.
|
||||
출력되는 각 섹션은 아래에 설명되어 있다.
|
||||
|
||||
### 주소 {#addresses}
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ weight: 30
|
|||
1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
|
||||
2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/)
|
||||
활성화 또는 구성.
|
||||
3. 적절한 경우, RBAC와 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
|
||||
3. 적절한 경우, RBAC과 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
|
||||
|
||||
{{< /caution >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ no_list: true
|
|||
|
||||
## 컨테이너 이미지
|
||||
[컨테이너 이미지](/ko/docs/concepts/containers/images/)는 애플리케이션을
|
||||
실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어있는(ready-to-run) 소프트웨어 패키지이다.
|
||||
실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어 있는(ready-to-run) 소프트웨어 패키지이다.
|
||||
여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리,
|
||||
그리고 모든 필수 설정에 대한 기본값이 포함된다.
|
||||
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도
|
|||
플러그인을 사용하거나 대역폭 제어 기능이 있는 자체 플러그인을 사용할 수 있다.
|
||||
|
||||
트래픽 셰이핑 지원을 활성화하려면, CNI 구성 파일 (기본값 `/etc/cni/net.d`)에 `bandwidth` 플러그인을
|
||||
추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어있는지 확인한다.
|
||||
추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어 있는지 확인한다.
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
|
|||
|
||||
접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
|
||||
|
||||
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어있다.
|
||||
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어 있다.
|
||||
|
||||
유효한 레이블 값은 다음과 같다.
|
||||
* 63 자 이하여야 하고 (공백일 수도 있음),
|
||||
|
|
@ -95,7 +95,7 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
|
|||
{{< /note >}}
|
||||
|
||||
{{< caution >}}
|
||||
일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어있는지 확인해야 한다.
|
||||
일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어 있는지 확인해야 한다.
|
||||
{{< /caution >}}
|
||||
|
||||
### _일치성 기준_ 요건
|
||||
|
|
@ -231,7 +231,7 @@ selector:
|
|||
- {key: environment, operator: NotIn, values: [dev]}
|
||||
```
|
||||
|
||||
`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다.
|
||||
`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어 있어 일치하기 위해서는 모든 요건을 만족해야 한다.
|
||||
|
||||
#### 노드 셋 선택
|
||||
|
||||
|
|
|
|||
|
|
@ -265,7 +265,7 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
|
|||
|
||||
`labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를
|
||||
선택적으로 지정할 수 있다(이것은 `labelSelector` 와 `topologyKey` 와 같은 수준의 정의이다).
|
||||
생략되어있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다.
|
||||
생략되어 있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다.
|
||||
|
||||
파드를 노드에 스케줄하려면 `requiredDuringSchedulingIgnoredDuringExecution` 어피니티와 안티-어피니티와
|
||||
연관된 `matchExpressions` 가 모두 충족되어야 한다.
|
||||
|
|
|
|||
|
|
@ -357,11 +357,11 @@ kubelet은 우선순위를 사용하여 파드의 [노드-압박(node-pressure)
|
|||
사용자는 QoS 클래스를 사용하여 어떤 파드가 축출될 것인지
|
||||
예상할 수 있다. kubelet은 다음의 요소들을 통해서 파드의 축출 순위를 매긴다.
|
||||
|
||||
1. 부족한 리소스 사용량이 요청을 초과하는지 여부
|
||||
1. 기아(starved) 리소스 사용량이 요청을 초과하는지 여부
|
||||
1. 파드 우선순위
|
||||
1. 요청 대비 리소스 사용량
|
||||
|
||||
더 자세한 내용은 [kubelet 축출에서 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
|
||||
더 자세한 내용은 [kubelet 축출을 위한 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
|
||||
참조한다.
|
||||
|
||||
kubelet 노드-압박 축출은 사용량이 요청을 초과하지 않는 경우
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
|
|||
|
||||
평평하고 넓은 클러스터 전체의 주소 공간에서 nginx를 실행하는 파드가 있다고 가정하자. 이론적으로는 이러한 파드와 직접 대화할 수 있지만, 노드가 죽으면 어떻게 되는가? 파드가 함께 죽으면 디플로이먼트에서 다른 IP를 가진 새로운 파드를 생성한다. 이 문제를 서비스가 해결한다.
|
||||
|
||||
쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다.
|
||||
쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어 있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다.
|
||||
|
||||
`kubectl expose` 를 사용해서 2개의 nginx 레플리카에 대한 서비스를 생성할 수 있다.
|
||||
|
||||
|
|
@ -346,7 +346,7 @@ kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert
|
|||
노출할 수 있다. 쿠버네티스는 이를 수행하는 2가지 방법인 NodePorts와
|
||||
LoadBalancers를지원한다. 마지막 섹션에서 생성된 서비스는 이미 `NodePort` 를 사용했기에
|
||||
노드에 공용 IP가 있는경우 nginx HTTPS 레플리카가 인터넷 트래픽을 처리할
|
||||
준비가 되어있다.
|
||||
준비가 되어 있다.
|
||||
|
||||
```shell
|
||||
kubectl get svc my-nginx -o yaml | grep nodePort -C 5
|
||||
|
|
|
|||
|
|
@ -233,7 +233,7 @@ DNS 정책은 파드별로 설정할 수 있다.
|
|||
자세한 내용을 확인할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면
|
||||
"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어 있지 않다면
|
||||
"ClusterFirst"가 기본값으로 사용된다.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ __podSelector__: 각 네트워크폴리시에는 정책이 적용되는 파드
|
|||
|
||||
__policyTypes__: 각 네트워크폴리시에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 네트워크폴리시에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, 네트워크폴리시에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
|
||||
|
||||
__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
|
||||
__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어 있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
|
||||
|
||||
__egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ _서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노
|
|||
|
||||
* 유효한 토폴로지 키는 현재 `kubernetes.io/hostname`,
|
||||
`topology.kubernetes.io/zone` 그리고 `topology.kubernetes.io/region` 로
|
||||
제한되어있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다.
|
||||
제한되어 있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다.
|
||||
|
||||
* 토폴로지 키는 유효한 레이블 키이어야 하며 최대 16개의 키를 지정할 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -358,7 +358,7 @@ targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다
|
|||
`flocker` 볼륨은 Flocker 데이터셋을 파드에 마운트할 수 있게 한다. 만약
|
||||
Flocker내에 데이터셋이 없는 경우, 먼저 Flocker
|
||||
CLI 또는 Flocker API를 사용해서 생성해야 한다. 만약 데이터셋이 이미 있다면
|
||||
Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이는 필요에
|
||||
Flocker는 파드가 스케줄 되어 있는 노드에 다시 연결한다. 이는 필요에
|
||||
따라 파드 간에 데이터를 공유할 수 있다는 의미이다.
|
||||
|
||||
{{< note >}}
|
||||
|
|
|
|||
|
|
@ -166,7 +166,7 @@ nodeAffinity:
|
|||
데몬셋의 파드와 통신할 수 있는 몇 가지 패턴은 다음과 같다.
|
||||
|
||||
- **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록
|
||||
구성되어있다. 그들은 클라이언트들을 가지지 않는다.
|
||||
구성되어 있다. 그들은 클라이언트들을 가지지 않는다.
|
||||
- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며,
|
||||
노드IP를 통해 파드에 접근할 수 있다.
|
||||
클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
|
||||
|
|
|
|||
|
|
@ -50,13 +50,13 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
|
|||
보다 정교한 선택 규칙의 적용이 가능하다.
|
||||
|
||||
{{< note >}}
|
||||
`.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된
|
||||
`.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어 있다. `matchLabels` 에 매핑된
|
||||
단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, `key` 필드는 "key"에 그리고 `operator`는 "In"에 대응되며
|
||||
`value` 배열은 "value"만 포함한다.
|
||||
매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
* `template` 필드에는 다음 하위 필드가 포함되어있다.
|
||||
* `template` 필드에는 다음 하위 필드가 포함되어 있다.
|
||||
* 파드는 `.metadata.labels` 필드를 사용해서 `app: nginx` 라는 레이블을 붙인다.
|
||||
* 파드 템플릿의 사양 또는 `.template.spec` 필드는
|
||||
파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는
|
||||
|
|
@ -1023,7 +1023,7 @@ echo $?
|
|||
|
||||
디플로이먼트의 `.spec.revisionHistoryLimit` 필드를 설정해서
|
||||
디플로이먼트에서 유지해야 하는 이전 레플리카셋의 수를 명시할 수 있다. 나머지는 백그라운드에서 가비지-수집이 진행된다.
|
||||
기본적으로 10으로 되어있다.
|
||||
기본적으로 10으로 되어 있다.
|
||||
|
||||
{{< note >}}
|
||||
명시적으로 이 필드를 0으로 설정하면 그 결과로 디플로이먼트의 기록을 전부 초기화를 하고,
|
||||
|
|
|
|||
|
|
@ -369,7 +369,7 @@ spec:
|
|||
다른 접근 방식들은 기존에 컨테이너화된 애플리케이션에 보다 쉽게 적용할 수 있다.
|
||||
|
||||
|
||||
여기에 트레이드오프가 요약되어있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다.
|
||||
여기에 트레이드오프가 요약되어 있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다.
|
||||
패턴 이름은 예시와 더 자세한 설명을 위한 링크이다.
|
||||
|
||||
| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정되지 않은 앱을 사용하는가? |
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ OwnerReference가 {{< glossary_tooltip term_id="controller" >}} 가 아니고
|
|||
|
||||
{{< codenew file="controllers/frontend.yaml" >}}
|
||||
|
||||
이 매니페스트를 `frontend.yaml`에 저장하고 쿠버네티스 클러스터에 적용하면 정의되어있는 레플리카셋이
|
||||
이 매니페스트를 `frontend.yaml`에 저장하고 쿠버네티스 클러스터에 적용하면 정의되어 있는 레플리카셋이
|
||||
생성되고 레플리카셋이 관리하는 파드가 생성된다.
|
||||
|
||||
```shell
|
||||
|
|
@ -128,7 +128,7 @@ frontend-wtsmm 1/1 Running 0 6m36s
|
|||
kubectl get pods frontend-b2zdv -o yaml
|
||||
```
|
||||
|
||||
메타데이터의 ownerReferences 필드에 설정되어있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
|
||||
메타데이터의 ownerReferences 필드에 설정되어 있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
|
|
@ -223,7 +223,7 @@ pod2 1/1 Running 0 36s
|
|||
|
||||
레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
|
||||
레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다.
|
||||
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
|
||||
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어 있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
|
||||
API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
|
||||
|
||||
레플리카셋 오브젝트의 이름은 유효한
|
||||
|
|
@ -233,7 +233,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
|
|||
|
||||
### 파드 템플릿
|
||||
|
||||
`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
|
||||
`.spec.template`은 레이블을 붙이도록 되어 있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
|
||||
우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다.
|
||||
이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.
|
||||
|
||||
|
|
@ -269,7 +269,7 @@ matchLabels:
|
|||
|
||||
### 레플리카셋과 해당 파드 삭제
|
||||
|
||||
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다.
|
||||
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다.
|
||||
|
||||
REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로
|
||||
설정해야 한다.
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ content_type: task
|
|||
최대 1개의 스토리지클래스를 기본값으로 표시할 수 있다는 것을 알아두자. 만약
|
||||
2개 이상이 기본값으로 표시되면, 명시적으로 `storageClassName` 가 지정되지 않은 `PersistentVolumeClaim` 은 생성될 수 없다.
|
||||
|
||||
1. 사용자가 선택한 스토리지클래스가 기본값으로 되어있는지 확인한다.
|
||||
1. 사용자가 선택한 스토리지클래스가 기본값으로 되어 있는지 확인한다.
|
||||
|
||||
```bash
|
||||
kubectl get storageclass
|
||||
|
|
|
|||
|
|
@ -447,7 +447,7 @@ Events:
|
|||
이 HorizontalPodAutoscaler 경우, 건강 상태의 여러 조건들을 볼 수 있다.
|
||||
첫 번째 `AbleToScale`는 HPA가 스케일을 가져오고 업데이트할 수 있는지,
|
||||
백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다.
|
||||
두 번째 `ScalingActive`는 HPA가 활성화되어있는지(즉 대상 레플리카 개수가 0이 아닌지),
|
||||
두 번째 `ScalingActive`는 HPA가 활성화되어 있는지(즉 대상 레플리카 개수가 0이 아닌지),
|
||||
원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우,
|
||||
일반적으로 메트릭을 가져오는데 문제가 있다.
|
||||
마지막으로, 마지막 조건인 `ScalingLimited`는
|
||||
|
|
|
|||
|
|
@ -398,7 +398,7 @@ behavior:
|
|||
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을
|
||||
다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터
|
||||
계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다.
|
||||
다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어있다.
|
||||
다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어 있다.
|
||||
|
||||
```yaml
|
||||
scaleDown:
|
||||
|
|
|
|||
|
|
@ -346,21 +346,21 @@ Events:
|
|||
[노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)를 이용하여
|
||||
파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다.
|
||||
|
||||
### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
|
||||
### 파드시큐리티폴리시(PodSecurityPolicy)로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
|
||||
|
||||
{{< note >}}
|
||||
PodSecurityPolicy는 쿠버네티스 v1.21에서 사용 중지되었으며, v1.25에서 제거될 예정이다.
|
||||
더 자세한 내용은 [PodSecurityPolicy 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다.
|
||||
파드시큐리티폴리시는 쿠버네티스 v1.21에서 사용 중단되었으며, v1.25에서 제거될 예정이다.
|
||||
더 자세한 내용은 [파드시큐리티폴리시 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
만약 PodSecurityPolicy 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
|
||||
PodSecurityPolicy를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
|
||||
만약 파드시큐리티폴리시 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
|
||||
파드시큐리티폴리시를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
|
||||
|
||||
```
|
||||
--enable-admission-plugins=PodSecurityPolicy[,others...]
|
||||
```
|
||||
|
||||
AppArmor 옵션은 PodSecurityPolicy의 어노테이션으로 지정할 수 있다.
|
||||
AppArmor 옵션은 파드시큐리티폴리시의 어노테이션으로 지정할 수 있다.
|
||||
|
||||
```yaml
|
||||
apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
|
||||
|
|
@ -390,7 +390,7 @@ AppArmor가 일반 사용자 버전이 되면 제거된다.
|
|||
### AppArmor와 함께 쿠버네티스 1.4로 업그레이드 하기 {#upgrading-to-kubernetes-v1.4-with-apparmor}
|
||||
|
||||
클러스터 버전을 v1.4로 업그레이드하기 위해 AppArmor쪽 작업은 없다.
|
||||
그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 PodSecurityPolicy 승인)을 거치지 않는다.
|
||||
그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 파드시큐리티폴리시 승인)을 거치지 않는다.
|
||||
그 노드에 허용 프로파일이 로드되면, 악의적인 사용자가 허가 프로필을 미리 적용하여
|
||||
파드의 권한을 docker-default 보다 높일 수 있다.
|
||||
이것이 염려된다면 `apparmor.security.beta.kubernetes.io` 어노테이션이 포함된
|
||||
|
|
@ -439,7 +439,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
|
|||
### 프로파일 참조 {#profile-reference}
|
||||
|
||||
- `runtime/default`: 기본 런타임 프로파일을 참조한다.
|
||||
- (기본 PodSecurityPolicy 없이) 프로파일을 지정하지 않고
|
||||
- (기본 파드시큐리티폴리시 없이) 프로파일을 지정하지 않고
|
||||
AppArmor를 사용하는 것과 동등하다.
|
||||
- 도커에서는 권한 없는 컨테이너의 경우는
|
||||
[`docker-default`](https://docs.docker.com/engine/security/apparmor/) 프로파일로,
|
||||
|
|
@ -451,7 +451,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
|
|||
|
||||
다른 어떤 프로파일 참조 형식도 유효하지 않다.
|
||||
|
||||
### PodSecurityPolicy 어노테이션 {#podsecuritypolicy-annotations}
|
||||
### 파드시큐리티폴리시 어노테이션 {#podsecuritypolicy-annotations}
|
||||
|
||||
아무 프로파일도 제공하지 않을 때에 컨테이너에 적용할 기본 프로파일을 지정하기
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue