Third Korean l10n work for release-1.19
- Fix issue with broken links in ko documents (#24190) - Fix issue with links to already translated ko documents (#24158) - Translate docs/reference/kubectl/docker-cli-to-kubectl/ into Korean (#24131) - Translate docs/setup/production-environment/tools/kubespray.md in Korean (#24144) - Translated titles into korean (#24394) - DNS subdomain translation corrected (#24393) - Update ko/docs/concepts/overview/working-with-objects/common-labels/ (#24370) - Translate tasks/job/coarse-parallel-processing-work-queue in Korean (#24218) - Update outdated files in the dev-1.19-ko.3 branch (#24151) - Add missing dot on job.md (#24084) Co-authored-by: chhanz <han0495@gmail.com> Co-authored-by: Yuuraa <yoorachoi8937@gmail.com> Co-authored-by: sushil <sushilktiwari.st@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com> Co-authored-by: Jonghun Park <jonghun.park.194@gmail.com> Co-authored-by: Leo <leo.lab001@gmail.com>
This commit is contained in:
June Yi
@@ -10,12 +10,6 @@ weight: 30
|
||||
테스트는 노드가 쿠버네티스를 위한 최소 요구조건을 만족하는지를 검증한다. 그리고 테스트를 통과한 노드는 쿠버네티스 클러스터에 참
|
||||
여할 자격이 주어진다.
|
||||
|
||||
## 제한 사항
|
||||
|
||||
쿠버네티스 1.5에서는 노드 적합성 테스트가 아래의 제약이 있다.
|
||||
|
||||
* 노드 적합성 테스트는 컨테이너 런타임으로 Docker만 지원한다.
|
||||
|
||||
## 노드 필수 구성 요소
|
||||
|
||||
노드 적합성 테스트를 실행하기 위해서는, 해당 노드는 표준 쿠버네티스 노드로서 동일한 전제조건을 만족해야 한다.
|
||||
|
||||
@@ -0,0 +1,119 @@
|
||||
---
|
||||
title: Kubespray로 쿠버네티스 설치하기
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Packet(베어메탈), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.
|
||||
|
||||
Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.
|
||||
|
||||
* 고가용성을 지닌 클러스터
|
||||
* 구성할 수 있는 속성들
|
||||
* 대부분의 인기있는 리눅스 배포판들에 대한 지원
|
||||
* Ubuntu 16.04, 18.04, 20.04
|
||||
* CentOS/RHEL/Oracle Linux 7, 8
|
||||
* Debian Buster, Jessie, Stretch, Wheezy
|
||||
* Fedora 31, 32
|
||||
* Fedora CoreOS
|
||||
* openSUSE Leap 15
|
||||
* Flatcar Container Linux by Kinvolk
|
||||
* 지속적인 통합 (CI) 테스트
|
||||
|
||||
클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, kubespray를 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), [kops](/docs/setup/production-environment/tools/kops/)와 [비교한 글](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)을 읽어보자.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 클러스터 생성하기
|
||||
|
||||
|
||||
### (1/5) 아래의 요건 충족하기
|
||||
|
||||
언더레이(underlay) [요건](https://github.com/kubernetes-sigs/kubespray#requirements)을 만족하는 프로비전 한다.
|
||||
|
||||
* **Ansible의 명령어를 실행하기 위해 Ansible v 2.9와 Python netaddr 라이브러리가 머신에 설치되어 있어야 한다**
|
||||
* **Ansible 플레이북을 실행하기 위해 2.11 (혹은 그 이상) 버전의 Jinja가 필요하다**
|
||||
* 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
|
||||
* 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다
|
||||
* **SSH 키**가 인벤토리의 모든 서버들에 복사되어야 한다
|
||||
* **방화벽은 관리되지 않는다**. 사용자가 예전 방식대로 고유한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다
|
||||
* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 한다. 그 뒤 `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다
|
||||
|
||||
Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다:
|
||||
|
||||
* 아래 클라우드 제공 업체를 위한 [Terraform](https://www.terraform.io/) 스크립트:
|
||||
* [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
|
||||
* [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
|
||||
* [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
|
||||
|
||||
### (2/5) 인벤토리 파일 구성하기
|
||||
|
||||
서버들을 프로비저닝 한 후, [Ansible의 인벤토리 파일](https://docs.ansible.com/ansible/intro_inventory.html)을 만들어야 한다. 수동으로 만들 수도 있고, 동적인 인벤토리 스크립트를 통해 만들 수도 있다. 더 많이 알고싶다면 " [나만의 인벤토리 만들기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)" 글을 확인하자.
|
||||
|
||||
### (3/5) 클러스터 디플로이먼트 계획하기
|
||||
|
||||
Kubespray에서는 디플로이먼트의 많은 속성들을 사용자가 정의(customize)할 수 있다:
|
||||
|
||||
* 디플로이먼트 모드의 선택: kubeadm 또는 그 외
|
||||
* CNI(네트워킹) 플러그인
|
||||
* DNS 설정
|
||||
* 컨트롤 플레인 선택: 네이티브/바이너리 또는 컨테이너화 된 것
|
||||
* 컴포넌트 버전
|
||||
* Calico 라우터 리플렉터
|
||||
* 컴포넌트 런타임 옵션
|
||||
* {{< glossary_tooltip term_id="docker" >}}
|
||||
* {{< glossary_tooltip term_id="containerd" >}}
|
||||
* {{< glossary_tooltip term_id="cri-o" >}}
|
||||
* 인증서 생성 방법
|
||||
|
||||
Kubespray의 [변수 파일들](https://docs.ansible.com/ansible/playbooks_variables.html)을 사용자가 정의할 수 있다. 만약 Kubespray를 막 시작한 경우, kubespray의 기본 설정값을 이용해 클러스터를 배포하고 Kubernetes를 탐색하는 것이 좋다.
|
||||
|
||||
### (4/5) 클러스터 배포하기
|
||||
|
||||
다음으로, 클러스터를 배포한다.
|
||||
|
||||
[Ansible-플레이북](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment)을 이용한 클러스터 디플로이먼트
|
||||
|
||||
```shell
|
||||
ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
|
||||
--private-key=~/.ssh/private_key
|
||||
```
|
||||
|
||||
규모가 큰 디플로이먼트는 (100개 이상의 노드) 최적의 결과를 얻기 위해 [특정한 조정](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md)을 필요로 할 수도 있다.
|
||||
|
||||
### (5/5) 디플로이먼트 검증하기
|
||||
|
||||
Kubespray는 Netchecker를 사용하여 파드 사이의 연결성과 DNS 해석을 검증할 방법을 제공한다. Netchecker는 netchecker-agents 파드들이 DNS 요청을 해석하고 기본(default) 네임스페이스 내부에서 서로에게 ping을 보낼 수 있도록 보장한다. 그 파드들은 나머지 워크로드의 유사한 동작을 모방하고 클러스터의 상태 표시기 역할을 한다.
|
||||
|
||||
## 클러스터 동작
|
||||
|
||||
Kubespray는 클러스터를 관리하기 위한 추가적인 플레이북, _scale_ 과 _upgrade_ 를 제공한다.
|
||||
|
||||
### 클러스터 스케일링하기
|
||||
|
||||
scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "[노드 추가하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)" 문서를 확인하자. remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "[노드 제거하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)" 문서를 확인하자.
|
||||
|
||||
### 클러스터 업그레이드 하기
|
||||
|
||||
upgrade-cluster 플레이북을 실행해 클러스터를 업그레이드 할 수 있다. 더 자세히 알고 싶다면 "[업그레이드](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)" 문서를 확인하자.
|
||||
|
||||
## 클린업
|
||||
|
||||
[reset 플레이북](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml)을 이용하여 노드들을 리셋하고 Kubespray로 설치된 모든 구성요소를 삭제할 수 있다.
|
||||
|
||||
{{< caution >}}
|
||||
reset 플레이북을 실행할 때, 실수로 프로덕션 클러스터를 타겟으로 삼지 않도록 해야 한다!
|
||||
{{< /caution >}}
|
||||
|
||||
## 피드백
|
||||
|
||||
* Slack 채널: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) ([이 곳](https://slack.k8s.io/)에서 초대를 받을 수 있다)
|
||||
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Kubespray의 [로드맵](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)에서 계획중인 작업을 확인해보자.
|
||||
|
||||
+11
-13
@@ -14,7 +14,7 @@ weight: 65
|
||||
|
||||
## 쿠버네티스의 윈도우 컨테이너
|
||||
|
||||
쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함하기만 하면 된다. 쿠버네티스의 [파드](/ko/docs/concepts/workloads/pods/pod-overview/)에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것만큼 간단하고 쉽다.
|
||||
쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함하기만 하면 된다. 쿠버네티스의 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것만큼 간단하고 쉽다.
|
||||
|
||||
윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 서버 2019는 윈도우에서 [쿠버네티스 노드](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)를 활성화하는 유일한 윈도우 운영 체제이다(kubelet, [컨테이너 런타임](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/containerd) 및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 [Microsoft 문서](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)를 참고한다.
|
||||
|
||||
@@ -62,7 +62,7 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨
|
||||
|
||||
윈도우에서 주요 쿠버네티스 요소는 리눅스와 동일한 방식으로 작동한다. 이 섹션에서는, 주요 워크로드 인에이블러(enabler) 일부와 이들이 윈도우에 매핑되는 방법에 대해 설명한다.
|
||||
|
||||
* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [파드](/ko/docs/concepts/workloads/pods/)
|
||||
|
||||
파드는 쿠버네티스의 기본 빌딩 블록이다 - 쿠버네티스 오브젝트 모델에서 생성하고 배포하는 가장 작고 간단한 단위. 동일한 파드에 윈도우 및 리눅스 컨테이너를 배포할 수 없다. 파드의 모든 컨테이너는 단일 노드로 스케줄되며 각 노드는 특정 플랫폼 및 아키텍처를 나타낸다. 다음과 같은 파드 기능, 속성 및 이벤트가 윈도우 컨테이너에서 지원된다.
|
||||
|
||||
@@ -81,7 +81,7 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨
|
||||
* 레플리카셋(ReplicaSet)
|
||||
* 레플리케이션컨트롤러(ReplicationController)
|
||||
* 디플로이먼트(Deployment)
|
||||
* 스테이트풀셋(StatefulSet)
|
||||
* 스테이트풀셋(StatefulSet)
|
||||
* 데몬셋(DaemonSet)
|
||||
* 잡(Job)
|
||||
* 크론잡(CronJob)
|
||||
@@ -198,7 +198,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
|
||||
윈도우에서는 다음 IPAM 옵션이 지원된다.
|
||||
|
||||
* [호스트-로컬](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local)
|
||||
* HNS IPAM(Inbox 플랫폼 IPAM, 이것은 IPAM이 설정되지 않은 경우 폴백(fallback)이다)
|
||||
* HNS IPAM(Inbox 플랫폼 IPAM, 이것은 IPAM이 설정되지 않은 경우 폴백(fallback)이다)
|
||||
* [Azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md)(azure-cni 전용)
|
||||
|
||||
##### 로드 밸런싱과 서비스
|
||||
@@ -255,9 +255,9 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
|
||||
|
||||
윈도우에는 리눅스처럼 out-of-memory 프로세스 킬러가 없다. 윈도우는 항상 모든 사용자 모드 메모리 할당을 가상으로 처리하며 페이지 파일은 필수이다. 결과적으로 윈도우는 리눅스와 같은 방식으로 메모리 부족 상태에 도달하지 않고, 메모리 부족(OOM)으로 인한 종료 대신 페이지를 디스크로 처리한다. 메모리가 과도하게 프로비저닝되고 모든 실제 메모리가 고갈되면, 페이징으로 인해 성능이 저하될 수 있다.
|
||||
|
||||
2단계 프로세스를 통해 적절한 범위 내에서 메모리 사용량을 유지할 수 있다. 먼저, kubelet 파라미터 `--kubelet-reserve` 그리고/또는 `--system-reserve`를 사용하여 노드(컨테이너 외부)의 메모리 사용량을 고려한다. 이렇게 하면 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)이 줄어든다. 워크로드를 배포할 때 컨테이너에 리소스 제한을 사용(limits만 설정하거나 limits이 requests과 같아야 함)한다. 또한 NodeAllocatable에서 빼고 노드가 가득차면 스케줄러가 더 많은 파드를 추가하지 못하도록 한다.
|
||||
2단계 프로세스를 통해 적절한 범위 내에서 메모리 사용량을 유지할 수 있다. 먼저, kubelet 파라미터 `--kubelet-reserve` 그리고/또는 `--system-reserve`를 사용하여 노드(컨테이너 외부)의 메모리 사용량을 고려한다. 이렇게 하면 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)이 줄어든다. 워크로드를 배포할 때 컨테이너에 리소스 제한을 사용(limits만 설정하거나 limits이 requests과 같아야 함)한다. 또한 NodeAllocatable에서 빼고 노드가 가득차면 스케줄러가 더 많은 파드를 추가하지 못하도록 한다.
|
||||
|
||||
오버 프로비저닝을 방지하는 모범 사례는 윈도우, 도커 및 쿠버네티스 프로세스를 고려하여 최소 2GB의 시스템 예약 메모리로 kubelet을 구성하는 것이다.
|
||||
오버 프로비저닝을 방지하는 모범 사례는 윈도우, 도커 및 쿠버네티스 프로세스를 고려하여 최소 2GB의 시스템 예약 메모리로 kubelet을 구성하는 것이다.
|
||||
|
||||
플래그의 동작은 아래에 설명된대로 다르게 동작한다.
|
||||
|
||||
@@ -581,7 +581,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
|
||||
1. DNS 확인(resolution)이 제대로 작동하지 않는다.
|
||||
|
||||
이 [섹션](#dns-limitations)에서 윈도우에 대한 DNS 제한을 확인한다.
|
||||
|
||||
|
||||
1. `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다.
|
||||
|
||||
이는 쿠버네티스 1.15 및 pause 인프라 컨테이너 `mcr.microsoft.com/k8s/core/pause:1.2.0`에서 구현되었다. 해당 버전 또는 최신 버전을 사용해야 한다.
|
||||
@@ -666,15 +666,13 @@ spec:
|
||||
|
||||
### kubeadm 및 클러스터 API를 사용한 배포
|
||||
|
||||
Kubeadm은 사용자가 쿠버네티스 클러스터를 배포하기 위한 사실상의 표준이
|
||||
되고 있다. kubeadm의 윈도우 노드 지원은 현재 작업 중이지만
|
||||
[여기](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)에서 가이드를 사용할 수 있다.
|
||||
또한 윈도우 노드가 적절하게 프로비저닝되도록 클러스터 API에
|
||||
Kubeadm은 사용자가 쿠버네티스 클러스터를 배포하기 위한 사실상의 표준이
|
||||
되고 있다. kubeadm의 윈도우 노드 지원은 현재 작업 중이지만
|
||||
[여기](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)에서 가이드를 사용할 수 있다.
|
||||
또한 윈도우 노드가 적절하게 프로비저닝되도록 클러스터 API에
|
||||
투자하고 있다.
|
||||
|
||||
### 몇 가지 기타 주요 기능
|
||||
* 그룹 관리 서비스 어카운트(Service Accounts)에 대한 베타 지원
|
||||
* 더 많은 CNI
|
||||
* 더 많은 스토리지 플러그인
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user