Merge pull request #33878 from jihoon-seo/220522_Update_outdated_dev-1.24-ko.1_M18-M31
[ko] Update outdated files in `dev-1.24-ko.1` (M18-M31)pull/34385/head
Kubernetes Prow Robot
GitHub
commit
076c39101f
|
|
@ -99,28 +99,28 @@ TERM 신호를 보내기 전에 실행을 완료해야 한다. 실행 중에 `Pr
|
|||
예를 들어, 훅을 전송하는 도중에 kubelet이 재시작된다면,
|
||||
Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.
|
||||
|
||||
### 디버깅 훅 핸들러
|
||||
### 훅 핸들러 디버깅
|
||||
|
||||
훅 핸들러의 로그는 파드 이벤트로 노출되지 않는다.
|
||||
만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다.
|
||||
`PostStart`의 경우, 이것은 `FailedPostStartHook` 이벤트이며,
|
||||
`PreStop`의 경우, 이것은 `FailedPreStopHook` 이벤트이다.
|
||||
이 이벤트는 `kubectl describe pod <파드_이름>`를 실행하면 볼 수 있다.
|
||||
다음은 이 커맨드 실행을 통한 이벤트 출력의 몇 가지 예다.
|
||||
실패한 `FailedPreStopHook` 이벤트를 직접 생성하려면, [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) 파일을 수정하여 postStart 명령을 "badcommand"로 변경하고 이를 적용한다.
|
||||
다음은 `kubectl describe pod lifecycle-demo` 를 실행하여 볼 수 있는 이벤트 출력 예시이다.
|
||||
|
||||
```
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
|
||||
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
|
||||
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
|
||||
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
|
||||
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal Scheduled 7s default-scheduler Successfully assigned default/lifecycle-demo to ip-XXX-XXX-XX-XX.us-east-2...
|
||||
Normal Pulled 6s kubelet Successfully pulled image "nginx" in 229.604315ms
|
||||
Normal Pulling 4s (x2 over 6s) kubelet Pulling image "nginx"
|
||||
Normal Created 4s (x2 over 5s) kubelet Created container lifecycle-demo-container
|
||||
Normal Started 4s (x2 over 5s) kubelet Started container lifecycle-demo-container
|
||||
Warning FailedPostStartHook 4s (x2 over 5s) kubelet Exec lifecycle hook ([badcommand]) for Container "lifecycle-demo-container" in Pod "lifecycle-demo_default(30229739-9651-4e5a-9a32-a8f1688862db)" failed - error: command 'badcommand' exited with 126: , message: "OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: \"badcommand\": executable file not found in $PATH: unknown\r\n"
|
||||
Normal Killing 4s (x2 over 5s) kubelet FailedPostStartHook
|
||||
Normal Pulled 4s kubelet Successfully pulled image "nginx" in 215.66395ms
|
||||
Warning BackOff 2s (x2 over 3s) kubelet Back-off restarting failed container
|
||||
```
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -29,8 +29,7 @@ weight: 10
|
|||
|
||||
레지스트리 호스트 이름을 지정하지 않으면, 쿠버네티스는 도커 퍼블릭 레지스트리를 의미한다고 가정한다.
|
||||
|
||||
이미지 이름 부분 다음에 _tag_ 를 추가할 수 있다(`docker` 와 `podman`
|
||||
등의 명령과 함께 사용).
|
||||
이미지 이름 부분 다음에 _tag_ 를 추가할 수 있다(`docker` 또는 `podman` 과 같은 명령을 사용할 때와 동일한 방식으로).
|
||||
태그를 사용하면 동일한 시리즈 이미지의 다른 버전을 식별할 수 있다.
|
||||
|
||||
이미지 태그는 소문자와 대문자, 숫자, 밑줄(`_`),
|
||||
|
|
@ -91,7 +90,7 @@ weight: 10
|
|||
`<image-name>:<tag>`를 `<image-name>@<digest>`로 교체한다.
|
||||
(예를 들어, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`).
|
||||
|
||||
이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 명시하는 것은 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해준다.
|
||||
이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 다이제스트로 명시하면 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해 준다.
|
||||
|
||||
파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가
|
||||
태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는
|
||||
|
|
@ -175,95 +174,11 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성
|
|||
|
||||
### 프라이빗 레지스트리에 인증하도록 노드 구성
|
||||
|
||||
노드에서 도커를 실행하는 경우, 프라이빗 컨테이너 레지스트리를 인증하도록
|
||||
도커 컨테이너 런타임을 구성할 수 있다.
|
||||
크리덴셜 설정에 대한 상세 지침은 사용하는 컨테이너 런타임 및 레지스트리에 따라 다르다. 가장 정확한 정보는 솔루션 설명서를 참조해야 한다.
|
||||
|
||||
이 방법은 노드 구성을 제어할 수 있는 경우에 적합하다.
|
||||
|
||||
{{< note >}}
|
||||
기본 쿠버네티스는 도커 구성에서 `auths` 와 `HttpHeaders` 섹션만 지원한다.
|
||||
도커 자격 증명 도우미(`credHelpers` 또는 `credsStore`)는 지원되지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
도커는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또는 `$HOME/.docker/config.json` 파일에 저장한다. 만약 동일한 파일을
|
||||
아래의 검색 경로 리스트에 넣으면, kubelet은 이미지를 풀 할 때 해당 파일을 자격 증명 공급자로 사용한다.
|
||||
|
||||
* `{--root-dir:-/var/lib/kubelet}/config.json`
|
||||
* `{cwd of kubelet}/config.json`
|
||||
* `${HOME}/.docker/config.json`
|
||||
* `/.docker/config.json`
|
||||
* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
|
||||
* `{cwd of kubelet}/.dockercfg`
|
||||
* `${HOME}/.dockercfg`
|
||||
* `/.dockercfg`
|
||||
|
||||
{{< note >}}
|
||||
kubelet 프로세스의 환경 변수에서 `HOME=/root` 를 명시적으로 설정해야 할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
프라이빗 레지스트리를 사용도록 사용자의 노드를 구성하기 위해서 권장되는 단계는 다음과 같다. 이
|
||||
예제의 경우, 사용자의 데스크탑/랩탑에서 아래 내용을 실행한다.
|
||||
|
||||
1. 사용하고 싶은 각 자격 증명 세트에 대해서 `docker login [서버]`를 실행한다. 이것은 여러분 PC의 `$HOME/.docker/config.json`를 업데이트한다.
|
||||
1. 편집기에서 `$HOME/.docker/config.json`를 보고 사용하고 싶은 자격 증명만 포함하고 있는지 확인한다.
|
||||
1. 노드의 리스트를 구한다. 예를 들면 다음과 같다.
|
||||
- 이름을 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
|
||||
- IP를 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
|
||||
1. 로컬의 `.docker/config.json`를 위의 검색 경로 리스트 중 하나에 복사한다.
|
||||
- 이를 테스트하기 위한 예: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
|
||||
|
||||
{{< note >}}
|
||||
프로덕션 클러스터의 경우, 이 설정을 필요한 모든 노드에 적용할 수 있도록
|
||||
구성 관리 도구를 사용한다.
|
||||
{{< /note >}}
|
||||
|
||||
프라이빗 이미지를 사용하는 파드를 생성하여 검증한다. 예를 들면 다음과 같다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: private-image-test-1
|
||||
spec:
|
||||
containers:
|
||||
- name: uses-private-image
|
||||
image: $PRIVATE_IMAGE_NAME
|
||||
imagePullPolicy: Always
|
||||
command: [ "echo", "SUCCESS" ]
|
||||
EOF
|
||||
```
|
||||
```
|
||||
pod/private-image-test-1 created
|
||||
```
|
||||
|
||||
만약 모든 것이 잘 작동한다면, 잠시 후에, 다음을 실행할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl logs private-image-test-1
|
||||
```
|
||||
그리고 커맨드 출력을 본다.
|
||||
```
|
||||
SUCCESS
|
||||
```
|
||||
|
||||
명령이 실패한 것으로 의심되는 경우 다음을 실행할 수 있다.
|
||||
```shell
|
||||
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`을 포함하거나 그것을 포함한 드라이브를 마운트해야 한다.
|
||||
|
||||
프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는
|
||||
프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다.
|
||||
프라이빗 컨테이너 이미지 레지스트리 구성 예시를 보려면,
|
||||
[프라이빗 레지스트리에서 이미지 가져오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry/)를 참조한다.
|
||||
해당 예시는 도커 허브에서 제공하는 프라이빗 레지스트리를 사용한다.
|
||||
|
||||
### config.json 파일 해석 {#config-json}
|
||||
|
||||
|
|
@ -332,6 +247,7 @@ kubelet은 인식된 모든 크리덴셜을 순차적으로 이용하여 이미
|
|||
이미지를 풀 해야 한다고 명시하면,
|
||||
kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다.
|
||||
|
||||
|
||||
### 미리 내려받은 이미지 {#pre-pulled-images}
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -362,6 +278,8 @@ kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다.
|
|||
|
||||
#### 도커 구성으로 시크릿 생성
|
||||
|
||||
레지스트리에 인증하기 위해서는, 레지스트리 호스트네임 뿐만 아니라,
|
||||
사용자 이름, 비밀번호 및 클라이언트 이메일 주소를 알아야 한다.
|
||||
대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다.
|
||||
|
||||
```shell
|
||||
|
|
@ -426,16 +344,15 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
|
|||
일반적인 유스케이스와 제안된 솔루션이다.
|
||||
|
||||
1. 비소유 이미지(예를 들어, 오픈소스)만 실행하는 클러스터의 경우. 이미지를 숨길 필요가 없다.
|
||||
- 도커 허브의 퍼블릭 이미지를 사용한다.
|
||||
- 퍼블릭 레지스트리의 퍼블릭 이미지를 사용한다.
|
||||
- 설정이 필요 없다.
|
||||
- 일부 클라우드 제공자는 퍼블릭 이미지를 자동으로 캐시하거나 미러링하므로, 가용성이 향상되고 이미지를 가져오는 시간이 줄어든다.
|
||||
1. 모든 클러스터 사용자에게는 보이지만, 회사 외부에는 숨겨야하는 일부 독점 이미지를
|
||||
실행하는 클러스터의 경우.
|
||||
- 호스트 된 프라이빗 [도커 레지스트리](https://docs.docker.com/registry/)를 사용한다.
|
||||
- 그것은 [도커 허브](https://hub.docker.com/signup)에 호스트 되어 있거나, 다른 곳에 되어 있을 것이다.
|
||||
- 위에 설명된 바와 같이 수동으로 .docker/config.json을 구성한다.
|
||||
- 호스트된 프라이빗 레지스트리를 사용한다.
|
||||
- 프라이빗 레지스트리에 접근해야 하는 노드에 수동 설정이 필요할 수 있다
|
||||
- 또는, 방화벽 뒤에서 읽기 접근 권한을 가진 내부 프라이빗 레지스트리를 실행한다.
|
||||
- 쿠버네티스 구성은 필요 없다.
|
||||
- 쿠버네티스 구성은 필요하지 않다.
|
||||
- 이미지 접근을 제어하는 호스팅된 컨테이너 이미지 레지스트리 서비스를 사용한다.
|
||||
- 그것은 수동 노드 구성에 비해서 클러스터 오토스케일링과 더 잘 동작할 것이다.
|
||||
- 또는, 노드의 구성 변경이 불편한 클러스터에서는, `imagePullSecrets`를 사용한다.
|
||||
|
|
@ -450,8 +367,6 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
|
|||
|
||||
|
||||
다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다.
|
||||
Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.json` 파일로 병합한다.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -16,9 +16,6 @@ weight: 20
|
|||
런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임
|
||||
구성은 파드의 컨테이너를 실행하는 데 사용된다.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 동기
|
||||
|
|
@ -62,12 +59,15 @@ weight: 20
|
|||
(`handler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: node.k8s.io/v1 # 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음
|
||||
# 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음
|
||||
apiVersion: node.k8s.io/v1
|
||||
kind: RuntimeClass
|
||||
metadata:
|
||||
name: myclass # 런타임클래스는 해당 이름을 통해서 참조됨
|
||||
# 런타임클래스 참조에 사용될 이름
|
||||
# 런타임클래스는 네임스페이스가 없는 리소스임
|
||||
handler: myconfiguration # 상응하는 CRI 설정의 이름임
|
||||
name: myclass
|
||||
# 상응하는 CRI 설정의 이름
|
||||
handler: myconfiguration
|
||||
```
|
||||
|
||||
런타임클래스 오브젝트의 이름은 유효한
|
||||
|
|
@ -81,8 +81,8 @@ handler: myconfiguration # 상응하는 CRI 설정의 이름임
|
|||
|
||||
## 사용
|
||||
|
||||
클러스터를 위해서 런타임클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에
|
||||
`runtimeClassName`를 명시한다. 예를 들면 다음과 같다.
|
||||
클러스터에 런타임클래스를 설정하고 나면,
|
||||
다음과 같이 파드 스펙에 `runtimeClassName`를 명시하여 해당 런타임클래스를 사용할 수 있다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -107,16 +107,6 @@ spec:
|
|||
|
||||
CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/production-environment/container-runtimes/)를 확인한다.
|
||||
|
||||
#### dockershim
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
|
||||
|
||||
dockershim은 쿠버네티스 v1.20에서 사용 중단되었으며, v1.24에서 제거될 것이다. 상세 사항은
|
||||
[dockershim 사용 중단](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)을 참고한다.
|
||||
|
||||
dockershim을 사용하는 경우 RuntimeClass는 런타임 핸들러를 `docker`로 고정한다.
|
||||
dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
|
||||
|
||||
#### {{< glossary_tooltip term_id="containerd" >}}
|
||||
|
||||
런타임 핸들러는 containerd의 구성 파일인 `/etc/containerd/config.toml` 통해 설정한다.
|
||||
|
|
@ -126,8 +116,8 @@ dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
|
|||
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
|
||||
```
|
||||
|
||||
더 자세한 containerd의 구성 문서를 살펴본다.
|
||||
https://github.com/containerd/cri/blob/master/docs/config.md
|
||||
더 자세한 내용은 containerd의 [구성 문서](https://github.com/containerd/cri/blob/master/docs/config.md)를
|
||||
살펴본다.
|
||||
|
||||
#### {{< glossary_tooltip term_id="cri-o" >}}
|
||||
|
||||
|
|
@ -166,21 +156,17 @@ RuntimeClass에 `scheduling` 필드를 지정하면, 이 RuntimeClass로 실행
|
|||
|
||||
### 파드 오버헤드
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
|
||||
|
||||
파드 실행과 연관되는 _오버헤드_ 리소스를 지정할 수 있다. 오버헤드를 선언하면
|
||||
클러스터(스케줄러 포함)가 파드와 리소스에 대한 결정을 내릴 때 처리를 할 수 있다.
|
||||
PodOverhead를 사용하려면, PodOverhead [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.)
|
||||
|
||||
파드 오버헤드는 런타임 클래스에서 `overhead` 필드를 통해 정의된다. 이 필드를 사용하면,
|
||||
해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가
|
||||
쿠버네티스 내에서 처리된다는 것을 보장할 수 있다.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
|
||||
- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
|
||||
- [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 개념에 대해 읽기
|
||||
|
|
|
|||
|
|
@ -39,6 +39,7 @@ no_list: true
|
|||
*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다.
|
||||
|
||||
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
|
||||
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
|
||||
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
|
||||
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
|
||||
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ weight: 10
|
|||
동적 등록을 통해 실행 중인 클러스터에서 커스텀 리소스가 나타나거나 사라질 수 있으며
|
||||
클러스터 관리자는 클러스터 자체와 독립적으로 커스텀 리소스를 업데이트 할 수 있다.
|
||||
커스텀 리소스가 설치되면 사용자는 *파드* 와 같은 빌트인 리소스와 마찬가지로
|
||||
[kubectl](/ko/docs/reference/kubectl/overview/)을 사용하여 해당 오브젝트를 생성하고
|
||||
[kubectl](/ko/docs/reference/kubectl/)을 사용하여 해당 오브젝트를 생성하고
|
||||
접근할 수 있다.
|
||||
|
||||
## 커스텀 컨트롤러
|
||||
|
|
|
|||
|
|
@ -344,12 +344,11 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
|
|||
다음은 장치 플러그인 구현의 예이다.
|
||||
|
||||
* [AMD GPU 장치 플러그인](https://github.com/RadeonOpenCompute/k8s-device-plugin)
|
||||
* 인텔 GPU, FPGA 및 QuickAssist 장치용 [인텔 장치 플러그인](https://github.com/intel/intel-device-plugins-for-kubernetes)
|
||||
* 인텔 GPU, FPGA, QAT, VPU, SGX, DSA, DLB 및 IAA 장치용 [인텔 장치 플러그인](https://github.com/intel/intel-device-plugins-for-kubernetes)
|
||||
* 하드웨어 지원 가상화를 위한 [KubeVirt 장치 플러그인](https://github.com/kubevirt/kubernetes-device-plugins)
|
||||
* [NVIDIA GPU 장치 플러그인](https://github.com/NVIDIA/k8s-device-plugin)
|
||||
* GPU를 지원하는 Docker 컨테이너를 실행할 수 있는 [nvidia-docker](https://github.com/NVIDIA/nvidia-docker) 2.0이 필요하다.
|
||||
* [컨테이너에 최적화된 OS를 위한 NVIDIA GPU 장치 플러그인](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
|
||||
* [RDMA 장치 플러그인](https://github.com/hustcat/k8s-rdma-device-plugin)
|
||||
* [SocketCAN 장치 플러그인](https://github.com/collabora/k8s-socketcan)
|
||||
* [Solarflare 장치 플러그인](https://github.com/vikaschoudhary16/sfc-device-plugin)
|
||||
* [SR-IOV 네트워크 장치 플러그인](https://github.com/intel/sriov-network-device-plugin)
|
||||
* Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin)
|
||||
|
|
|
|||
|
|
@ -11,17 +11,20 @@ weight: 10
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
쿠버네티스의 네트워크 플러그인은 몇 가지 종류가 있다.
|
||||
쿠버네티스 {{< skew currentVersion >}} 버전은 클러스터 네트워킹을 위해 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 플러그인을 지원한다.
|
||||
클러스터와 호환되며 사용자의 요구 사항을 충족하는 CNI 플러그인을 사용해야 한다. 더 넓은 쿠버네티스 생태계에 다양한 플러그인이 존재한다(오픈소스 및 클로즈드 소스).
|
||||
|
||||
* CNI 플러그인: 상호 운용성을 위해 설계된 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 명세를 준수한다.
|
||||
* 쿠버네티스는 CNI 명세의 [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) 릴리스를 따른다.
|
||||
* Kubenet 플러그인: `bridge` 와 `host-local` CNI 플러그인을 사용하여 기본 `cbr0` 구현한다.
|
||||
[v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) 이상의
|
||||
CNI 스펙과 호환되는 CNI 플러그인을 사용해야 한다.
|
||||
쿠버네티스 플러그인은
|
||||
CNI 스펙 [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/SPEC.md)과 호환되는
|
||||
플러그인의 사용을 권장한다(플러그인은 여러 스펙 버전과 호환 가능).
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 설치
|
||||
|
||||
kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에 공통된 기본 네트워크가 있다. 플러그인은 시작할 때 플러그인을 검색하고, 찾은 것을 기억하며, 파드 라이프사이클에서 적절한 시간에 선택한 플러그인을 실행한다(CRI는 자체 CNI 플러그인을 관리하므로 도커에만 해당됨). 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
|
||||
CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다. CRI는 자체 CNI 플러그인을 관리한다. 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
|
||||
|
||||
* `cni-bin-dir`: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다.
|
||||
* `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 "cni"이다.
|
||||
|
|
@ -129,35 +132,8 @@ metadata:
|
|||
...
|
||||
```
|
||||
|
||||
### kubenet
|
||||
|
||||
Kubenet은 리눅스에서만 사용할 수 있는 매우 기본적이고, 간단한 네트워크 플러그인이다. 그 자체로는, 크로스-노드 네트워킹 또는 네트워크 정책과 같은 고급 기능을 구현하지 않는다. 일반적으로 노드 간, 또는 단일 노드 환경에서 통신을 위한 라우팅 규칙을 설정하는 클라우드 제공자와 함께 사용된다.
|
||||
|
||||
Kubenet은 `cbr0` 라는 리눅스 브리지를 만들고 각 쌍의 호스트 끝이 `cbr0` 에 연결된 각 파드에 대한 veth 쌍을 만든다. 쌍의 파드 끝에는 구성 또는 컨트롤러 관리자를 통해 노드에 할당된 범위 내에서 할당된 IP 주소가 지정된다. `cbr0` 에는 호스트에서 활성화된 일반 인터페이스의 가장 작은 MTU와 일치하는 MTU가 지정된다.
|
||||
|
||||
플러그인에는 몇 가지 사항이 필요하다.
|
||||
|
||||
* 표준 CNI `bridge`, `lo` 및 `host-local` 플러그인은 최소 0.2.0 버전이 필요하다. Kubenet은 먼저 `/opt/cni/bin` 에서 검색한다. 추가 검색 경로를 제공하려면 `cni-bin-dir` 을 지정한다. 처음 검색된 디렉터리가 적용된다.
|
||||
* 플러그인을 활성화하려면 Kubelet을 `--network-plugin=kubenet` 인수와 함께 실행해야 한다.
|
||||
* Kubelet은 `--non-masquerade-cidr=<clusterCidr>` 인수와 함께 실행하여 이 범위 밖 IP로의 트래픽이 IP 마스커레이드(masquerade)를 사용하도록 해야 한다.
|
||||
* `--pod-cidr` kubelet 커맨드라인 옵션 또는 `--allocate-node-cidrs=true --cluster-cidr=<cidr>` 컨트롤러 관리자 커맨드라인 옵션을 통해 노드에 IP 서브넷을 할당해야 한다.
|
||||
|
||||
### MTU 사용자 정의 (kubenet 사용)
|
||||
|
||||
최상의 네트워킹 성능을 얻으려면 MTU를 항상 올바르게 구성해야 한다. 네트워크 플러그인은 일반적으로 합리적인 MTU를
|
||||
유추하려고 시도하지만, 때로는 로직에 따라 최적의 MTU가 지정되지 않는다. 예를 들어,
|
||||
도커 브리지나 다른 인터페이스에 작은 MTU가 지정되어 있으면, kubenet은 현재 해당 MTU를 선택한다. 또는
|
||||
IPSEC 캡슐화를 사용하는 경우, MTU를 줄여야 하며, 이 계산은 대부분의
|
||||
네트워크 플러그인에서 범위를 벗어난다.
|
||||
|
||||
필요한 경우, `network-plugin-mtu` kubelet 옵션을 사용하여 MTU를 명시 적으로 지정할 수 있다. 예를 들어,
|
||||
AWS에서 `eth0` MTU는 일반적으로 9001이므로, `--network-plugin-mtu=9001` 을 지정할 수 있다. IPSEC를 사용하는 경우
|
||||
캡슐화 오버헤드를 허용하도록 `--network-plugin-mtu=8873` 과 같이 IPSEC을 줄일 수 있다.
|
||||
|
||||
이 옵션은 네트워크 플러그인에 제공된다. 현재 **kubenet만 `network-plugin-mtu` 를 지원한다**.
|
||||
|
||||
## 용법 요약
|
||||
|
||||
* `--network-plugin=cni` 는 `--cni-bin-dir`(기본값 `/opt/cni/bin`)에 있는 실제 CNI 플러그인 바이너리와 `--cni-conf-dir`(기본값 `/etc/cni/net.d`)에 있는 CNI 플러그인 구성과 함께 `cni` 네트워크 플러그인을 사용하도록 지정한다.
|
||||
* `--network-plugin=kubenet` 은 `/opt/cni/bin` 또는 `cni-bin-dir` 에 있는 CNI `bridge`, `lo` 및 `host-local` 플러그인과 함께 `kubenet` 네트워크 플러그인을 사용하도록 지정한다.
|
||||
* 현재 kubenet 네트워크 플러그인에서만 사용하는 `--network-plugin-mtu=9001` 은 사용할 MTU를 지정한다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
|
|
|||
|
|
@ -111,6 +111,7 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
|
|||
{{% thirdparty-content %}}
|
||||
|
||||
* [Charmed Operator Framework](https://juju.is/)
|
||||
* [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework)
|
||||
* [kubebuilder](https://book.kubebuilder.io/) 사용하기
|
||||
* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET 오퍼레이터 SDK)
|
||||
* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
|
||||
|
|
|
|||
|
|
@ -230,4 +230,3 @@ spec:
|
|||
* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/ko/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다.
|
||||
* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
|
||||
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색
|
||||
* [svc-cat.io](https://svc-cat.io/docs/) 살펴보기
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ card:
|
|||
|
||||
컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있다. 그러나
|
||||
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고,
|
||||
사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 여러 VM에서
|
||||
사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 여러 머신에서
|
||||
실행되는 컨트롤 플레인 설정의 예제를 보려면
|
||||
[kubeadm을 사용하여 고가용성 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/high-availability/)를 확인해본다.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ card:
|
|||
쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예:
|
||||
파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다.
|
||||
|
||||
대부분의 작업은 [kubectl](/ko/docs/reference/kubectl/overview/)
|
||||
대부분의 작업은 [kubectl](/ko/docs/reference/kubectl/)
|
||||
커맨드 라인 인터페이스 또는 API를 사용하는
|
||||
[kubeadm](/ko/docs/reference/setup-tools/kubeadm/)과
|
||||
같은 다른 커맨드 라인 도구를 통해 수행할 수 있다.
|
||||
|
|
@ -82,18 +82,42 @@ IDL(인터페이스 정의 언어) 파일을 참고한다.
|
|||
|
||||
### OpenAPI V3
|
||||
|
||||
{{< feature-state state="alpha" for_k8s_version="v1.23" >}}
|
||||
{{< feature-state state="beta" for_k8s_version="v1.24" >}}
|
||||
|
||||
쿠버네티스 v1.23은 OpenAPI v3 API 발행(publishing)에 대한 초기 지원을 제공한다.
|
||||
이는 알파 기능이며 기본적으로 비활성화되어 있다.
|
||||
쿠버네티스 {{< param "version" >}} 버전은 OpenAPI v3 API 발행(publishing)에 대한 베타 지원을 제공한다.
|
||||
이는 베타 기능이며 기본적으로 활성화되어 있다.
|
||||
kube-apiserver 구성 요소에
|
||||
`OpenAPIV3` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여
|
||||
이 알파 기능을 활성화할 수 있다.
|
||||
`OpenAPIV3` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화하여
|
||||
이 베타 기능을 비활성화할 수 있다.
|
||||
|
||||
이 기능이 활성화되면, 쿠버네티스 API 서버는
|
||||
통합된(aggregated) OpenAPI v3 스펙을 쿠버네티스 그룹 버전별로
|
||||
`/openapi/v3/apis/<group>/<version>` 엔드포인트에 제공한다.
|
||||
사용할 수 있는 요청 헤더는 아래의 표를 참고한다.
|
||||
`/openapi/v3` 디스커버리 엔드포인트는 사용 가능한 모든
|
||||
그룹/버전의 목록을 제공한다. 이 엔드포인트는 JSON 만을 반환한다.
|
||||
이러한 그룹/버전은 다음과 같은 형식으로 제공된다.
|
||||
```json
|
||||
{
|
||||
"paths": {
|
||||
...
|
||||
"api/v1": {
|
||||
"serverRelativeURL": "/openapi/v3/api/v1?hash=CC0E9BFD992D8C59AEC98A1E2336F899E8318D3CF4C68944C3DEC640AF5AB52D864AC50DAA8D145B3494F75FA3CFF939FCBDDA431DAD3CA79738B297795818CF"
|
||||
},
|
||||
"apis/admissionregistration.k8s.io/v1": {
|
||||
"serverRelativeURL": "/openapi/v3/apis/admissionregistration.k8s.io/v1?hash=E19CC93A116982CE5422FC42B590A8AFAD92CDE9AE4D59B5CAAD568F083AD07946E6CB5817531680BCE6E215C16973CD39003B0425F3477CFD854E89A9DB6597"
|
||||
},
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
위의 상대 URL은 변경 불가능한(immutable) OpenAPI 상세를 가리키고 있으며,
|
||||
이는 클라이언트에서의 캐싱을 향상시키기 위함이다.
|
||||
같은 목적을 위해 API 서버는 적절한 HTTP 캐싱 헤더를
|
||||
설정한다(`Expires`를 1년 뒤로, `Cache-Control`을 `immutable`).
|
||||
사용 중단된 URL이 사용되면, API 서버는 최신 URL로의 리다이렉트를 반환한다.
|
||||
|
||||
쿠버네티스 API 서버는
|
||||
쿠버네티스 그룹 버전에 따른 OpenAPI v3 스펙을
|
||||
`/openapi/v3/apis/<group>/<version>?hash=<hash>` 엔드포인트에 게시한다.
|
||||
|
||||
사용 가능한 요청 헤더 목록은 아래의 표를 참고한다.
|
||||
|
||||
<table>
|
||||
<caption style="display:none"> OpenAPI v3 질의에 사용할 수 있는 유효한 요청 헤더 값</caption>
|
||||
|
|
@ -126,9 +150,6 @@ kube-apiserver 구성 요소에
|
|||
</tbody>
|
||||
</table>
|
||||
|
||||
`/openapi/v3` 디스커버리 엔드포인트는 사용 가능한 모든
|
||||
그룹/버전의 목록을 제공한다. 이 엔드포인트는 JSON 만을 반환한다.
|
||||
|
||||
## 지속성
|
||||
|
||||
쿠버네티스는 오브젝트의 직렬화된 상태를
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ spec과 status간의 차이에 대응한다.
|
|||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
|
||||
```
|
||||
|
||||
그 출력 내용은 다음과 유사하다.
|
||||
|
|
@ -83,14 +83,22 @@ deployment.apps/nginx-deployment created
|
|||
|
||||
오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [쿠버네티스 API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
|
||||
|
||||
예를 들어, API 내 파드에 대한 상세 정보는 [`spec` 필드](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)에 대한 레퍼런스에서,
|
||||
디플로이먼트에 대한 상세 정보는 [`spec` 필드](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec)에 대한 레퍼런스에서 확인할 수 있다.
|
||||
해당 API 레퍼런스 페이지에서 PodSpec과 DeploymentSpec에 대해 언급된 내용을 볼 수 있다. 이 이름들은 쿠버네티스가 API를 구현하는데 사용한 Go 언어 코드 구현의 세부 내용이다.
|
||||
|
||||
예를 들어, 파드 API 레퍼런스를 보려면
|
||||
[`spec` 필드](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)를 참조한다.
|
||||
각 파드에 대해, `.spec` 필드는 파드 및 파드의 원하는 상태(desired state)를
|
||||
기술한다(예: 파드의 각 컨테이너에 대한 컨테이너 이미지).
|
||||
오브젝트 상세에 대한 또 다른 예시는 스테이트풀셋 API의
|
||||
[`spec` 필드](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)이다.
|
||||
스테이트풀셋의 경우, `.spec` 필드는 스테이트풀셋 및 스테이트풀셋의 원하는 상태(desired state)를 기술한다.
|
||||
스테이트풀셋의 `.spec`에는 파드 오브젝트에 대한
|
||||
[템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이 존재한다.
|
||||
이 템플릿은 스테이트풀셋 명세를 만족시키기 위해
|
||||
스테이트풀셋 컨트롤러가 생성할 파드에 대한 상세 사항을 설명한다.
|
||||
서로 다른 종류의 오브젝트는 서로 다른 `.status`를 가질 수 있다.
|
||||
다시 한번 말하자면, 각 API 레퍼런스 페이지는 각 오브젝트 타입에 대해 해당 `.status` 필드의 구조와 내용에 대해 소개한다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [파드](/ko/docs/concepts/workloads/pods/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
|
||||
* 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
|
||||
* API 개념의 더 많은 설명은 [쿠버네티스 API 사용](/ko/docs/reference/using-api/)을 본다.
|
||||
|
|
|
|||
|
|
@ -442,7 +442,7 @@ pods 0 10
|
|||
|
||||
### 네임스페이스 간 파드 어피니티 쿼터
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
|
||||
|
||||
오퍼레이터는 네임스페이스를 교차하는 어피니티가 있는 파드를 가질 수 있는 네임스페이스를
|
||||
제한하기 위해 `CrossNamespacePodAffinity` 쿼터 범위를 사용할 수 있다. 특히, 파드 어피니티 용어의
|
||||
|
|
@ -493,10 +493,6 @@ plugins:
|
|||
해당 필드를 사용하는 파드 수보다 크거나 같은 하드 제한이 있는 경우에만
|
||||
파드 어피니티에서 `namespaces` 및 `namespaceSelector` 를 사용할 수 있다.
|
||||
|
||||
이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다.
|
||||
|
||||
## 요청과 제한의 비교 {#requests-vs-limits}
|
||||
|
||||
컴퓨트 리소스를 할당할 때 각 컨테이너는 CPU 또는 메모리에 대한 요청과 제한값을 지정할 수 있다.
|
||||
|
|
|
|||
Loading…
Reference in New Issue