[ko] Update outdated files in dev-1.21-ko.1 (p3)
This commit is contained in:
@@ -70,7 +70,7 @@ sudo sysctl --system
|
||||
|
||||
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용자 |
|
||||
|----------|-----------|------------|-------------------------|---------------------------|
|
||||
| TCP | 인바운드 | 6443* | 쿠버네티스 API 서버 | 모두 |
|
||||
| TCP | 인바운드 | 6443\* | 쿠버네티스 API 서버 | 모두 |
|
||||
| TCP | 인바운드 | 2379-2380 | etcd 서버 클라이언트 API | kube-apiserver, etcd |
|
||||
| TCP | 인바운드 | 10250 | kubelet API | 자체, 컨트롤 플레인 |
|
||||
| TCP | 인바운드 | 10251 | kube-scheduler | 자체 |
|
||||
@@ -294,33 +294,17 @@ Flatcar Container Linux 배포판은 `/usr` 디렉터리를 읽기 전용 파일
|
||||
kubelet은 이제 kubeadm이 수행할 작업을 알려 줄 때까지 크래시루프(crashloop) 상태로
|
||||
기다려야 하므로 몇 초마다 다시 시작된다.
|
||||
|
||||
## 컨트롤 플레인 노드에서 kubelet이 사용하는 cgroup 드라이버 구성
|
||||
## cgroup 드라이버 구성
|
||||
|
||||
도커를 사용할 때, kubeadm은 kubelet 용 cgroup 드라이버를 자동으로 감지하여
|
||||
런타임 중에 `/var/lib/kubelet/config.yaml` 파일에 설정한다.
|
||||
|
||||
다른 CRI를 사용하는 경우, 다음과 같이 `cgroupDriver` 값을 `kubeadm init` 에 전달해야 한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: kubelet.config.k8s.io/v1beta1
|
||||
kind: KubeletConfiguration
|
||||
cgroupDriver: <value>
|
||||
```
|
||||
|
||||
자세한 내용은 [구성 파일과 함께 kubeadm init 사용](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)을 참고한다.
|
||||
|
||||
`cgroupfs` 가 이미 kubelet의 기본값이기 때문에, 사용자의
|
||||
CRI cgroup 드라이버가 `cgroupfs` 가 아닌 **경우에만** 위와 같이 설정해야 한다.
|
||||
|
||||
{{< note >}}
|
||||
`--cgroup-driver` 플래그가 kubelet에 의해 사용 중단되었으므로, `/var/lib/kubelet/kubeadm-flags.env`
|
||||
또는 `/etc/default/kubelet`(RPM에 대해서는 `/etc/sysconfig/kubelet`)에 있는 경우, 그것을 제거하고 대신 KubeletConfiguration을
|
||||
사용한다(기본적으로 `/var/lib/kubelet/config.yaml` 에 저장됨).
|
||||
{{< /note >}}
|
||||
|
||||
CRI-O 및 containerd와 같은 다른 컨테이너 런타임에 대한 cgroup 드라이버의
|
||||
자동 감지에 대한 작업이 진행 중이다.
|
||||
컨테이너 런타임과 kubelet은
|
||||
["cgroup 드라이버"](/ko/docs/setup/production-environment/container-runtimes/)라는 속성을 갖고 있으며,
|
||||
cgroup 드라이버는 리눅스 머신의 cgroup 관리 측면에 있어서 중요하다.
|
||||
|
||||
{{< warning >}}
|
||||
컨테이너 런타임과 kubelet의 cgroup 드라이버를 일치시켜야 하며, 그렇지 않으면 kubelet 프로세스에 오류가 발생한다.
|
||||
|
||||
더 자세한 사항은 [cgroup 드라이버 설정하기](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다.
|
||||
{{< /warning >}}
|
||||
|
||||
## 문제 해결
|
||||
|
||||
@@ -328,5 +312,4 @@ kubeadm에 문제가 있는 경우, [문제 해결 문서](/docs/setup/productio
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [kubeadm을 사용하여 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
|
||||
|
||||
@@ -1,65 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 컨트롤 플레인을 자체 호스팅하기 위해 쿠버네티스 클러스터 구성하기
|
||||
content_type: concept
|
||||
weight: 100
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
### 쿠버네티스 컨트롤 플레인 자체 호스팅하기 {#self-hosting}
|
||||
|
||||
kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플레인을 만들 수 있도록
|
||||
해준다. API 서버, 컨트롤러 매니저 및 스케줄러와 같은 주요 구성 요소가 정적(static) 파일을
|
||||
통해 kubelet에 구성된 [스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/)
|
||||
대신 쿠버네티스 API를 통해 구성된 [데몬셋(DaemonSet) 파드](/ko/docs/concepts/workloads/controllers/daemonset/)
|
||||
로 실행된다.
|
||||
|
||||
자체 호스팅된 클러스터를 만들려면 [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)
|
||||
명령어를 확인한다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
#### 주의사항
|
||||
|
||||
{{< caution >}}
|
||||
이 기능은 클러스터를 지원되지 않는 상태로 전환하여 더 이상 클러스터를 관리할 수 없게 만든다.
|
||||
이것은 `kubeadm upgrade`를 포함한다.
|
||||
{{< /caution >}}
|
||||
|
||||
1. 1.8 이후 버전에서 자체 호스팅은 몇 가지 중요한 한계가 있다.
|
||||
특히 자체 호스팅된 클러스터는 수동 조정 없이는
|
||||
_컨트롤 플레인 노드를 재부팅하고 나서 복구할 수 없다._
|
||||
|
||||
1. 기본적으로 자체 호스팅된 컨트롤 플레인 파드는
|
||||
[`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) 볼륨에서 불러 온
|
||||
자격 증명에 의존한다. 초기 생성을 제외하고, 이러한 자격 증명은 kubeadm에 의해
|
||||
관리되지 않는다.
|
||||
|
||||
1. 컨트롤 플레인의 자체 호스팅된 부분에는 스태틱 파드로 실행되는 etcd가
|
||||
포함되지 않는다.
|
||||
|
||||
#### 프로세스
|
||||
|
||||
자체 호스팅 부트스트랩 프로세스는 [kubeadm 설계
|
||||
문서](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting)에 기록되어 있다.
|
||||
|
||||
요약하면 `kubeadm alpha selfhosting`은 다음과 같이 작동한다.
|
||||
|
||||
1. 부트스트랩 스태틱 컨트롤 플레인이 실행되고 정상 상태가 될 때까지 기다린다.
|
||||
이것은 자체 호스팅이 없는 `kubeadm init` 프로세스와 동일하다.
|
||||
|
||||
1. 스태틱 컨트롤 플레인 파드 매니페스트를 사용하여 자체 호스팅된 컨트롤
|
||||
플레인을 실행할 데몬셋 매니페스트 집합을 구성한다. 또한 필요한 경우
|
||||
해당 매니페스트를 수정한다. 예를 들어, 시크릿을 위한 새로운 볼륨을
|
||||
추가한다.
|
||||
|
||||
1. `kube-system` 네임스페이스에 데몬셋을 생성하고 결과 파드가 실행될 때까지
|
||||
대기한다.
|
||||
|
||||
1. 일단 자체 호스팅된 파드가 동작하면 관련 스태틱 파드가 삭제되고
|
||||
kubeadm은 계속해서 다음 구성 요소를 설치한다.
|
||||
이것은 kubelet이 스태틱 파드를 멈추게 한다.
|
||||
|
||||
1. 기존의 컨트롤 플레인이 멈추면 새롭게 자체 호스팅된 컨트롤 플레인은
|
||||
리스닝 포트에 바인딩하여 활성화할 수 있다.
|
||||
@@ -68,7 +68,7 @@ Kubespray에서는 디플로이먼트의 많은 속성들을 사용자가 정의
|
||||
* {{< glossary_tooltip term_id="cri-o" >}}
|
||||
* 인증서 생성 방법
|
||||
|
||||
Kubespray의 [변수 파일들](https://docs.ansible.com/ansible/playbooks_variables.html)을 사용자가 정의할 수 있다. 만약 Kubespray를 막 시작한 경우, kubespray의 기본 설정값을 이용해 클러스터를 배포하고 Kubernetes를 탐색하는 것이 좋다.
|
||||
Kubespray의 [변수 파일들](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html)을 사용자가 정의할 수 있다. 만약 Kubespray를 처음 접하는 경우, kubespray의 기본 설정값을 이용해 클러스터를 배포하고 Kubernetes를 탐색하는 것이 좋다.
|
||||
|
||||
### (4/5) 클러스터 배포하기
|
||||
|
||||
|
||||
Reference in New Issue
Block a user