Fourth Korean l10n work for release-1.15 (#16063)
* ko: update translation in reference/glossary/* (#15776) * Update outdated files partly in dev-1.15-ko.4 (#15856) * ko: update translation in tasks/debug-application-cluster/resource-metrics-pipeline (#15798) * ko: translate setup/production-environment/tools/control-plane-flags (#15820) * ko: translate user-guide-windows-containers (#15730) * ko: update translation in reference/glossary/* (#15761) * ko: Update outdated files partly in dev-1.15-ko.4 (#15790) * ko: fix corrupt date in glossary/static-pod (#15911) * ko: translate user-guide-windows-nodes (#15759) * Translate /docs/concepts/configuration/overview/ in Korean (#15803) * ko: translate setup/production-environment/tools/ha-topology (#15819) * ko: translate tasks/administer-cluster/network-policy-provider (#15846) * Translate tasks/inject-data-application/define-command-argument-container in Korea (#15933) * ko: translate concepts/configuration/organize-cluster-access-kubeconfig (#15871) * Translate working-with-objects/common-labels.md in Korean (#15832) * Translate concepts/workloads/pods/disruptions.md in Korean (#15926) * Translate tasks/access-application-cluster/web-ui/dashboard in Korean (#15852) * Translate concepts/overview/working-with-objects/labels.md in Korean (#15831) * ko: translate guestbook-logs-metrics-with-elk (#15894) * ko: translate tasks/administer-cluster/highly-available-master (#15928) Co-Authored-By: Yoon <learder@gmail.com> Co-Authored-By: Eden <longlg88@naver.com> Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com> Co-Authored-By: Seokho Son <shsongist@gmail.com> Co-Authored-By: Lawrence Kay <lkay9495@hotmail.com> Co-Authored-By: alice_k106 <alice_k106@naver.com> Co-Authored-By: Cheolgu Kim <lapee79@gmail.com>
This commit is contained in:
Seokho Son
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
270aaf1f16
commit
c82a912e29
@@ -37,8 +37,8 @@ card:
|
||||
|커뮤니티 |생태계 |
|
||||
| ------------ | -------- |
|
||||
| [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
|
||||
| [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
|
||||
| [Kubernetes IN Docker](https://github.com/kubernetes-sigs/kind) | [Minishift](https://docs.okd.io/latest/minishift/)|
|
||||
| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
|
||||
| | [Minishift](https://docs.okd.io/latest/minishift/)|
|
||||
| | [MicroK8s](https://microk8s.io/)|
|
||||
| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
|
||||
| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
|
||||
@@ -71,14 +71,14 @@ card:
|
||||
| [Cisco Container Platform](https://cisco.com/go/containers) | | | ✔ | | |
|
||||
| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ |
|
||||
| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔|
|
||||
| [Canonical](https://www.ubuntu.com/kubernetes/docs/quickstart) | | ✔ | | ✔ |✔ | ✔
|
||||
| [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔
|
||||
| [Containership](https://containership.io/containership-platform) | ✔ |✔ | | | |
|
||||
| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔
|
||||
| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | |
|
||||
| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔
|
||||
| [Fedora (멀티 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | | | | ✔ | ✔
|
||||
| [Fedora (단일 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/) | | | | | | ✔
|
||||
| [Gardner](https://gardener.cloud/) | |✔ | | ✔ | |
|
||||
| [Gardener](https://gardener.cloud/) | |✔ | | ✔ | |
|
||||
| [Giant Swarm](https://giantswarm.io/) | ✔ | ✔ | ✔ | |
|
||||
| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | |
|
||||
| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
|
||||
|
||||
@@ -452,10 +452,8 @@ export no_proxy=$no_proxy,$(minikube ip)
|
||||
```
|
||||
|
||||
## 알려진 이슈
|
||||
* 클라우드 공급자를 필요로 하는 기능은 Minikube에서 동작하지 않는다. 여기에는 다음이 포함된다.
|
||||
* 로드밸런서
|
||||
* 다중 노드를 위한 기능들이다. 여기에는 다음이 포함된다.
|
||||
* 진보된 스케쥴링 정책
|
||||
|
||||
다중 노드가 필요한 기능은 Minukube에서 동작하지 않는다.
|
||||
|
||||
## 설계
|
||||
|
||||
|
||||
@@ -187,7 +187,7 @@ apt-get install cri-o-1.13
|
||||
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
|
||||
|
||||
# 선행 조건 설치
|
||||
yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/
|
||||
yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
|
||||
|
||||
# CRI-O 설치
|
||||
yum install --nogpgcheck cri-o
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "kubeadm으로 클러스터 구성하기"
|
||||
weight: 10
|
||||
---
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
reviewers:
|
||||
title: kubeadm으로 컨트롤 플레인 사용자 정의하기
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="1.12" state="stable" >}}
|
||||
|
||||
kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러와 같은 컨트롤 플레인 구성요소에 전달되는 기본 플래그 `extraArgs` 필드를 노출한다. 이 구성요소는 다음 필드를 사용하도록 정의되어 있다.
|
||||
|
||||
- `apiServer`
|
||||
- `controllerManager`
|
||||
- `scheduler`
|
||||
|
||||
`extraArgs` 필드는 `key: value` 쌍으로 구성되어 있다. 컨트롤 플레인 구성요소를 위한 플래그를 대체하려면 다음을 수행한다.
|
||||
|
||||
1. 사용자 구성에서 적절한 필드를 추가한다.
|
||||
2. 필드에 대체할 플래그를 추가한다.
|
||||
3. `kubeadm init`에 `--config <YOUR CONFIG YAML>` 파라미터를 추가해서 실행한다.
|
||||
|
||||
각 필드의 구성에서 자세한 정보를 보려면,
|
||||
[API 참고 문서](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2#ClusterConfiguration)에서 확인해 볼 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
`kubeadm config print init-defaults`를 실행하고 원하는 파일에 출력을 저장하여 기본값인 `ClusterConfiguration` 오브젝트를 생성할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## APIServer 플래그
|
||||
|
||||
자세한 내용은 [kube-apiserver에 대한 참고 문서](/docs/reference/command-line-tools-reference/kube-apiserver/)를 확인한다.
|
||||
|
||||
사용 예:
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
kind: ClusterConfiguration
|
||||
kubernetesVersion: v1.13.0
|
||||
apiServer:
|
||||
extraArgs:
|
||||
advertise-address: 192.168.0.103
|
||||
anonymous-auth: "false"
|
||||
enable-admission-plugins: AlwaysPullImages,DefaultStorageClass
|
||||
audit-log-path: /home/johndoe/audit.log
|
||||
```
|
||||
|
||||
## 컨트롤러매니저 플래그
|
||||
|
||||
자세한 내용은 [kube-controller-manager에 대한 참고 문서](/docs/reference/command-line-tools-reference/kube-controller-manager/)를 확인한다.
|
||||
|
||||
사용 예:
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
kind: ClusterConfiguration
|
||||
kubernetesVersion: v1.13.0
|
||||
controllerManager:
|
||||
extraArgs:
|
||||
cluster-signing-key-file: /home/johndoe/keys/ca.key
|
||||
bind-address: 0.0.0.0
|
||||
deployment-controller-sync-period: "50"
|
||||
```
|
||||
|
||||
## 스케줄러 플래그
|
||||
|
||||
자세한 내용은 [kube-scheduler에 대한 참고 문서](/docs/reference/command-line-tools-reference/kube-scheduler/)를 확인한다.
|
||||
|
||||
사용 예:
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
kind: ClusterConfiguration
|
||||
kubernetesVersion: v1.13.0
|
||||
scheduler:
|
||||
extraArgs:
|
||||
address: 0.0.0.0
|
||||
config: /home/johndoe/schedconfig.yaml
|
||||
kubeconfig: /home/johndoe/kubeconfig.yaml
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 고가용성 토폴로지 선택
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 페이지는 고가용성(HA) 쿠버네티스 클러스터의 토플로지를 구성하는 두 가지 선택 사항을 설명한다.
|
||||
|
||||
다음과 같이 HA 클러스터를 구성할 수 있다.
|
||||
|
||||
- etcd 노드와 컨트롤 플레인 노드를 함께 위치시키는 중첩된(stacked) 컨트롤 플레인 노드 방식
|
||||
- etcd와 컨트롤 플레인이 분리된 노드에서 운영되는 외부 etcd 노드 방식
|
||||
|
||||
HA 클러스터를 구성하기 전에 각 토플로지의 장단점을 주의 깊게 고려해야 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 중첩된 etcd 토플로지
|
||||
|
||||
중첩된 HA 클러스터는 etcd에서 제공하는 분산 데이터 저장소 클러스터를,
|
||||
컨트롤 플레인 구성 요소를 실행하는 kubeadm으로 관리되는 노드에 의해서 형성된 클러스터 상단에
|
||||
중첩하는 [토플로지](https://en.wikipedia.org/wiki/Network_topology)이다.
|
||||
|
||||
각 컨트롤 플레인 노드는 `kube-apiserver`, `kube-scheduler`, `kube-controller-manager` 인스턴스를 운영한다.
|
||||
`kube-apiserver`는 로드 밸런서를 이용하여 워커 노드에 노출되어 있다.
|
||||
|
||||
각 컨트롤 플레인 노드는 지역 etcd 맴버를 생성하고
|
||||
이 etcd 맴버는 오직 해당 노드의 `kube-apiserver`와 통신한다.
|
||||
비슷한 방식이 지역의 `kube-controller-manager`와 `kube-scheduler`에도 적용된다.
|
||||
|
||||
이 토플로지는 컨트롤 플레인과 etcd 맴버가 같은 노드에 묶여 있다.
|
||||
이는 외부 etcd 노드의 클러스터를 구성하는 것보다는 단순하며 복제 관리도 간단하다.
|
||||
|
||||
그러나 중첩된 클러스터는 커플링에 실패할 위험이 있다. 한 노드가 다운되면 etcd 맴버와 컨트롤 플레인을 모두 잃어버리고,
|
||||
중복성도 손상된다. 더 많은 컨트롤 플레인 노드를 추가하여 이 위험을 완화할 수 있다.
|
||||
|
||||
그러므로 HA 클러스터를 위해 최소 3개인 중첩된 컨트롤 플레인 노드를 운영해야 한다.
|
||||
|
||||
이는 kubeadm의 기본 토플로지이다. 지역 etcd 맴버는
|
||||
`kubeadm init`와 `kubeadm join --control-plane` 을 이용할 때에 컨트롤 플레인 노드에 자동으로 생성된다.
|
||||
|
||||
|
||||
|
||||
## 외부 etcd 토플로지
|
||||
|
||||
외부 etcd를 이용하는 HA 클러스터는 etcd로 제공한 분산된 데이터 스토리지 클러스터가 컨트롤 플레인 구성 요소를 운영하는 노드로 형성하는 클러스터의 외부에 있는 [토플로지](https://en.wikipedia.org/wiki/Network_topology)이다.
|
||||
|
||||
중첩된 etcd 토플로지와 유사하게, 외부 etcd 토플로지에 각 컨트롤 플레인 노드는 `kube-apiserver`, `kube-scheduler`, `kube-controller-manager`의 인스턴스를 운영한다. 그리고 `kube-apiserver`는 로드 밸런서를 이용하여 워커노드에 노출한다. 그러나 etcd 맴버는 분리된 호스트에서 운영되고, 각 etcd 호스트는 각 컨트롤 플레인 노드의 `kube-apiserver`와 통신한다.
|
||||
|
||||
이 토플로지는 컨트롤 플레인과 etcd 맴버를 분리한다. 이는 그러므로
|
||||
컨트롤 플레인 인스턴스나 etcd 맴버를 잃는 충격이 덜하고,
|
||||
클러스터 중복성에 있어 중첩된 HA 토플로지만큼 영향을 미치지 않는다.
|
||||
|
||||
그러나, 이 토플로지는 중첩된 토플로지에 비해 호스트 개수가 두배나 필요하다.
|
||||
이 토플로지로 HA 클러스터를 구성하기 위해서는 최소한 3개의 컨트롤 플레인과 3개의 etcd 노드가 필요하다.
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
- [kubeadm을 이용하여 고가용성 클러스터 구성하기](/docs/setup/production-environment/tools/kubeadm/high-availability/)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "쿠버네티스에서 윈도우"
|
||||
weight: 50
|
||||
---
|
||||
BIN
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 109 KiB |
+138
@@ -0,0 +1,138 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드
|
||||
content_template: templates/concept
|
||||
weight: 75
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
많은 조직에서 실행하는 서비스와 애플리케이션의 상당 부분이 윈도우 애플리케이션으로 구성된다. 이 가이드는 쿠버네티스에서 윈도우 컨테이너를 구성하고 배포하는 단계를 안내한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 목표
|
||||
|
||||
* 윈도우 노드에서 윈도우 컨테이너를 실행하는 예시 디플로이먼트를 구성한다.
|
||||
* (선택) 그룹 매니지드 서비스 어카운트(GMSA)를 이용한 사용자 파드를 위한 액티브 디렉터리 신원(Active Directory Identity)을 구성한다.
|
||||
|
||||
## 시작하기 전에
|
||||
|
||||
* [윈도우 서버에서 운영하는 마스터와 워커 노드](../user-guide-windows-nodes)를 포함한 쿠버네티스 클러스터를 생성한다.
|
||||
* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. [Kubectl 커맨드](/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. 아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다.
|
||||
|
||||
## 시작하기: 윈도우 컨테이너 배포하기
|
||||
|
||||
쿠버네티스에서 윈도우 컨테이너를 배포하려면, 먼저 예시 애플리케이션을 생성해야 한다. 아래 예시 YAML 파일은 간단한 웹서버 애플리케이션을 생성한다. 아래 내용으로 채운 서비스 스펙을 `win-webserver.yaml`로 생성하자.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: win-webserver
|
||||
labels:
|
||||
app: win-webserver
|
||||
spec:
|
||||
ports:
|
||||
# 이 서비스에서 제공하는 포트
|
||||
- port: 80
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: win-webserver
|
||||
type: NodePort
|
||||
---
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app: win-webserver
|
||||
name: win-webserver
|
||||
spec:
|
||||
replicas: 2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: win-webserver
|
||||
name: win-webserver
|
||||
spec:
|
||||
containers:
|
||||
- name: windowswebserver
|
||||
image: mcr.microsoft.com/windows/servercore:ltsc2019
|
||||
command:
|
||||
- powershell.exe
|
||||
- -command
|
||||
- "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; "
|
||||
nodeSelector:
|
||||
beta.kubernetes.io/os: windows
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
포트 매핑도 지원하지만, 간략한 예시를 위해 컨테이너 포트 80을 직접 서비스로 노출한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. 모든 노드가 건강한지 확인한다.
|
||||
|
||||
```bash
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
1. 서비스를 배포하고 파드 갱신을 지켜보자.
|
||||
|
||||
```bash
|
||||
kubectl apply -f win-webserver.yaml
|
||||
kubectl get pods -o wide -w
|
||||
```
|
||||
|
||||
이 서비스가 정확히 배포되면 모든 파드는 Ready로 표기된다. 지켜보기를 중단하려면, Ctrl+C 를 누르자.
|
||||
|
||||
1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.
|
||||
|
||||
* 윈도우 노드에 파드당 두 컨테이너, `docker ps`를 사용한다.
|
||||
* 리눅스 마스터에서 나열된 두 파드, `kubectl get pods`를 사용한다.
|
||||
* 네트워크를 통한 노드에서 파드 간에 통신, 리눅스 마스터에서 `curl`을 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
|
||||
* 파드와 파드 간에 통신, `docker exec` 나 `kubectl exec`를 이용해 파드 간에 핑(ping)한다(윈도우 노드를 여럿가지고 있다면 호스트를 달리하며).
|
||||
* 서비스와 파드 간에 통신, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스 IP 주소(`kubectl get services`로 보여지는)로 실행한다.
|
||||
* 서비스 검색(discovery), 쿠버네티스 [기본 DNS 접미사](/docs/concepts/services-networking/dns-pod-service/#services)와 서비스 이름으로 `curl`을 실행한다.
|
||||
* 인바운드 연결, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
|
||||
* 아웃바운드 연결, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.
|
||||
|
||||
{{< note >}}
|
||||
윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. 윈도우 파드만 서비스 IP 주소로 접근할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
## 그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기
|
||||
|
||||
쿠버네티스 v1.14부터 윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다. 그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능, 단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다. GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다. 윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자.
|
||||
|
||||
## 테인트(Taint)와 톨러레이션(Toleration)
|
||||
|
||||
오늘날 사용자는 리눅스와 윈도우 워크로드를 특정 OS 노드별로 보존하기 위해 테인트와 노드 셀렉터(nodeSelector)의 조합을 이용해야 한다. 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다.
|
||||
|
||||
### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기
|
||||
|
||||
사용자는 윈도우 컨테이너가 테인트와 톨러레이션을 이용해서 적절한 호스트에서 스케줄링되기를 보장할 수 있다. 오늘날 모든 쿠버네티스 노드는 다음 기본 레이블을 가지고 있다.
|
||||
|
||||
* beta.kubernetes.io/os = [windows|linux]
|
||||
* beta.kubernetes.io/arch = [amd64|arm64|...]
|
||||
|
||||
파드 사양에 노드 셀렉터를 `"beta.kubernetes.io/os": windows`와 같이 지정하지 않았다면, 그 파드는 리눅스나 윈도우, 아무 호스트에나 스케줄링될 수 있다. 윈도우 컨테이너는 윈도우에서만 운영될 수 있고 리눅스 컨테이너는 리눅스에서만 운영될 수 있기 때문에 이는 문제를 일으킬 수 있다. 가장 좋은 방법은 노드 셀렉터를 사용하는 것이다.
|
||||
|
||||
그러나 많은 경우 사용자는 이미 존재하는 대량의 리눅스 컨테이너용 디플로이먼트를 가지고 있을 뿐만 아니라, 헬름(Helm) 차트 커뮤니티 같은 상용 구성의 에코시스템이나, 오퍼레이터(Operator) 같은 프로그래밍 방식의 파드 생성 사례가 있음을 알고 있다. 이런 상황에서는 노드 셀렉터를 추가하는 구성 변경을 망설일 수 있다. 이에 대한 대안은 테인트를 사용하는 것이다. Kubelet은 등록하는 동안 테인트를 설정할 수 있기 때문에, 윈도우에서만 운영할 때에 자동으로 테인트를 추가하기 쉽다.
|
||||
|
||||
예를 들면, `--register-with-taints='os=Win1809:NoSchedule'`
|
||||
|
||||
모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여). 윈도우 파드가 윈도우 노드에 스케줄링되려면, 윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
|
||||
|
||||
```yaml
|
||||
nodeSelector:
|
||||
"beta.kubernetes.io/os": windows
|
||||
tolerations:
|
||||
- key: "os"
|
||||
operator: "Equal"
|
||||
value: "Win1809"
|
||||
effect: "NoSchedule"
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,271 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 쿠버네티스에서 윈도우 노드 추가 가이드
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
쿠버네티스 플랫폼은 이제 리눅스와 윈도우 컨테이너 모두 운영할 수 있다. 윈도우 노드도 클러스터에 등록할 수 있다. 이 가이드는 다음을 어떻게 하는지 보여준다.
|
||||
|
||||
* 윈도우 노드를 클러스터에 등록하기
|
||||
* 리눅스와 윈도우에서 동작하는 파드가 상호 간에 통신할 수 있게 네트워크를 구성하기
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 시작하기 전에
|
||||
|
||||
* 윈도우 컨테이너를 호스트하는 윈도우 노드를 구성하려면 [윈도우 서버 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)를 소유해야 한다. 클러스터를 위해서 소속 기관의 라이선스를 사용하거나, Microsoft, 리셀러로 부터 취득할 수 있으며, GCP, AWS, Azure와 같은 주요 클라우드 제공자의 마켓플레이스를 통해 윈도우 서버를 운영하는 가상머신을 프로비저닝하여 취득할 수도 있다. [사용시간이 제한된 시험판](https://www.microsoft.com/en-us/cloud-platform/windows-server-trial)도 활용 가능하다.
|
||||
|
||||
* 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 클러스터를 구축한다.(몇 가지 예시는 [kubeadm으로 단일 컨트롤플레인 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), [AKS Engine](/docs/setup/production-environment/turnkey/azure/), [GCE](/docs/setup/production-environment/turnkey/gce/), [AWS](/docs/setup/production-environment/turnkey/aws/)를 포함한다)
|
||||
|
||||
## 시작하기: 사용자 클러스터에 윈도우 노드 추가하기
|
||||
|
||||
### IP 주소 체계 설계하기
|
||||
|
||||
쿠버네티스 클러스터 관리를 위해 실수로 네트워크 충돌을 일으키지 않도록 IP 주소에 대해 신중히 설계해야 한다. 이 가이드는 [쿠버네티스 네트워킹 개념](/docs/concepts/cluster-administration/networking/)에 익숙하다 가정한다.
|
||||
|
||||
클러스터를 배포하려면 다음 주소 공간이 필요하다.
|
||||
|
||||
| 서브넷 / 주소 범위 | 비고 | 기본값 |
|
||||
| --- | --- | --- |
|
||||
| 서비스 서브넷 | 라우트 불가한 순수한 가상 서브넷으로 네트워크 토플로지에 관계없이 파드에서 서비스로 단일화된 접근을 제공하기 위해 사용한다. 서비스 서브넷은 노드에서 실행 중인 `kube-proxy`에 의해서 라우팅 가능한 주소 공간으로(또는 반대로) 번역된다. | 10.96.0.0/12 |
|
||||
| 클러스터 서브넷 | 클러스터 내에 모든 파드에 사용되는 글로벌 서브넷이다. 각 노드에는 파드가 사용하기 위한 /24 보다 작거나 같은 서브넷을 할당한다. 서브넷은 클러스터 내에 모든 파드를 수용할 수 있을 정도로 충분히 큰 값이어야 한다. *최소 서브넷*의 크기를 계산하려면: `(노드의 개수) + (노드의 개수 * 구성하려는 노드 당 최대 파드 개수)`. 예: 노드 당 100개 파드인 5 노드짜리 클러스터 = `(5) + (5 * 100) = 505.` | 10.244.0.0/16 |
|
||||
| 쿠버네티스 DNS 서비스 IP | DNS 확인 및 클러스터 서비스 검색에 사용되는 서비스인 `kube-dns`의 IP 주소이다. | 10.96.0.10 |
|
||||
|
||||
클러스터에 IP 주소를 얼마나 할당해야 할지 결정하기 위해 '쿠버네티스에서 윈도우 컨테이너: 지원되는 기능: 네트워킹'에서 소개한 네트워킹 선택 사항을 검토하자.
|
||||
|
||||
### 윈도우에서 실행되는 구성 요소
|
||||
|
||||
쿠버네티스 컨트롤 플레인이 리눅스 노드에서 운영되는 반면, 다음 요소는 윈도우 노드에서 구성되고 운영된다.
|
||||
|
||||
1. kubelet
|
||||
2. kube-proxy
|
||||
3. kubectl (선택적)
|
||||
4. 컨테이너 런타임
|
||||
|
||||
v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes/releases](https://github.com/kubernetes/kubernetes/releases)에서 받아온다. kubeadm, kubectl, kubelet, kube-proxy의 Windows-amd64 바이너리는 CHANGELOG 링크에서 찾아볼 수 있다.
|
||||
|
||||
### 네트워크 구성
|
||||
|
||||
리눅스 기반의 쿠버네티스 마스터 노드를 가지고 있다면 네트워킹 솔루션을 선택할 준비가 된 것이다. 이 가이드는 단순화를 위해 VXLAN 방식의 플라넬(Flannel)을 사용하여 설명한다.
|
||||
|
||||
#### 리눅스 컨트롤러에서 VXLAN 방식으로 플라넬 구성하기
|
||||
|
||||
1. 플라넬을 위해 쿠버네티스 마스터를 준비한다.
|
||||
|
||||
클러스터의 쿠버네티스 마스터에서 사소한 준비를 권장한다. 플라넬을 사용할 때에 iptables 체인으로 IPv4 트래픽을 브릿지할 수 있게 하는 것은 추천한다. 이는 다음 커맨드를 이용하여 수행할 수 있다.
|
||||
|
||||
```bash
|
||||
sudo sysctl net.bridge.bridge-nf-call-iptables=1
|
||||
```
|
||||
|
||||
1. 플라넬 다운로드 받고 구성하기
|
||||
|
||||
가장 최신의 플라넬 메니페스트를 다운로드한다.
|
||||
|
||||
```bash
|
||||
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
|
||||
```
|
||||
|
||||
VXLAN 네트워킹 벡엔드를 가능하게 하기 위해 수정할 곳은 두 곳이다.
|
||||
|
||||
아래 단계를 적용하면 `kube-flannel.yml`의 `net-conf.json`부분을 다음과 같게 된다.
|
||||
|
||||
```json
|
||||
net-conf.json: |
|
||||
{
|
||||
"Network": "10.244.0.0/16",
|
||||
"Backend": {
|
||||
"Type": "vxlan",
|
||||
"VNI" : 4096,
|
||||
"Port": 4789
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
{{< note >}}리눅스의 플라넬과 윈도우의 플라넬이 상호운용하기 위해서 `VNI`는 반드시 4096이고, `Port`는 4789여야 한다. 다른 VNI는 곧 지원될 예정이다. [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)에서
|
||||
이 필드의 설명 부분을 보자.{{< /note >}}
|
||||
|
||||
1. `kube-flannel.yml`의 `net-conf.json` 부분을 거듭 확인하자.
|
||||
1. 클러스터 서브넷(예, "10.244.0.0/16")은 IP 주소 설계에 따라 설정되어야 한다.
|
||||
* VNI 4096 은 벡엔드에 설정한다.
|
||||
* Port 4789 는 벡엔드에 설정한다.
|
||||
2. `kube-flannel.yml`의 `cni-conf.json` 부분에서 네트워크 이름을 `vxlan0`로 바꾼다.
|
||||
|
||||
|
||||
`cni-conf.json`는 다음과 같다.
|
||||
|
||||
```json
|
||||
cni-conf.json: |
|
||||
{
|
||||
"name": "vxlan0",
|
||||
"plugins": [
|
||||
{
|
||||
"type": "flannel",
|
||||
"delegate": {
|
||||
"hairpinMode": true,
|
||||
"isDefaultGateway": true
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "portmap",
|
||||
"capabilities": {
|
||||
"portMappings": true
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
1. 플라넬 yaml 을 적용하고 확인하기
|
||||
|
||||
플라넬 구성을 적용하자.
|
||||
|
||||
```bash
|
||||
kubectl apply -f kube-flannel.yml
|
||||
```
|
||||
|
||||
다음은 플라넬 파드는 리눅스 기반이라 [여기](https://github.com/Microsoft/SDN/blob/1d5c055bb195fecba07ad094d2d7c18c188f9d2d/Kubernetes/flannel/l2bridge/manifests/node-selector-patch.yml) 나온 노드 셀렉터 패치를 플라넬 데몬셋 파드에 적용한다.
|
||||
|
||||
```bash
|
||||
kubectl patch ds/kube-flannel-ds-amd64 --patch "$(cat node-selector-patch.yml)" -n=kube-system
|
||||
```
|
||||
|
||||
몇 분 뒤에 플라넬 파드 네트워크가 배포되었다면, 모든 파드에서 운영 중인 것을 확인할 수 있다.
|
||||
|
||||
```bash
|
||||
kubectl get pods --all-namespaces
|
||||
```
|
||||
|
||||
|
||||
|
||||
플라넬 데몬셋에 노드 셀렉터가 적용되었음을 확인한다.
|
||||
|
||||
```bash
|
||||
kubectl get ds -n kube-system
|
||||
```
|
||||
|
||||
|
||||
|
||||
#### 윈도우 워커 조인
|
||||
|
||||
이번 단원은 맨 땅에서부터 온프레미스 클러스터에 가입하기까지 윈도우 노드 구성을 다룬다. 클러스터가 클라우드상에 있다면, 다음 단원에 있는 클라우드에 특정한 가이드를 따르도록 된다.
|
||||
|
||||
#### 윈도우 노드 준비하기
|
||||
{{< note >}}
|
||||
윈도우 단원에서 모든 코드 부분은 높은 권한(Admin)으로 파워쉘(PowerShell) 환경에서 구동한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. 도커(Docker) 설치(시스템 리부팅 필요)
|
||||
|
||||
쿠버네티스는 [도커](https://www.docker.com/)를 컨테이너 엔진으로 사용하므로, 도커를 설치해야 한다. [공식 문서 설치 요령](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon#install-docker), [도커 명령](https://store.docker.com/editions/enterprise/docker-ee-server-windows)을 따라 해보거나 다음의 *권장하는* 단계를 시도하자.
|
||||
|
||||
```PowerShell
|
||||
Enable-WindowsOptionalFeature -FeatureName Containers
|
||||
Restart-Computer -Force
|
||||
Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
|
||||
Install-Package -Name Docker -ProviderName DockerMsftProvider
|
||||
```
|
||||
|
||||
네트워크 프록시 안쪽에서 작업한다면 다음 파워쉘 환경 변수를 반드시 정의하자.
|
||||
|
||||
```PowerShell
|
||||
[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
|
||||
[Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
|
||||
```
|
||||
|
||||
리부팅 후에 다음 오류를 보게되면, 도커 서비스를 수동으로 재시작해야 한다.
|
||||
|
||||
|
||||
|
||||
```PowerShell
|
||||
Start-Service docker
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`pause`(인프라스트럭처) 이미지는 Microsoft 컨테이너 레지스트리(MCR)에 등록되어 있다. `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`로 접근할 수 있다. `DOCKERFILE`은 https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat 에 있다.
|
||||
{{< /note >}}
|
||||
|
||||
1. 쿠버네티스를 위한 윈도우 디렉터리 준비하기
|
||||
|
||||
쿠버네티스 바이너리와 배포 스크립트와 구성 파일을 저장할 "윈도우를 위한 쿠버네티스" 디렉터리를 생성한다.
|
||||
|
||||
```PowerShell
|
||||
mkdir c:\k
|
||||
```
|
||||
|
||||
1. 쿠버네티스 인증서 복사하기
|
||||
|
||||
쿠버네티스 인증서 파일인 `$HOME/.kube/config`을 [리눅스 컨트롤러](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/creating-a-linux-master#collect-cluster-information)에서 윈도우 노드의 새로운 `C:\k` 디렉터리로 복사한다.
|
||||
|
||||
팁: 노드 간에 구성 파일 전송을 위해 [xcopy](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy), [WinSCP](https://winscp.net/eng/download.php)나 [WinSCP 파워쉘 래퍼](https://www.powershellgallery.com/packages/WinSCP/5.13.2.0)같은 도구를 이용할 수 있다.
|
||||
|
||||
1. 쿠버네티스 바이너리 다운로드 하기
|
||||
|
||||
쿠버네티스르 운영을 가능하게 하기 위해 먼저 `kubelet`과 `kube-proxy` 바이너리를 다운로드해야 한다. 이 바이너리를 [최신 릴리스](https://github.com/kubernetes/kubernetes/releases/)의 CHANGELOG.md 파일에 노드 바이너리 링크에서 다운로드 한다. 예를 들어 'kubernetes-node-windows-amd64.tar.gz'. 또한 클라이언트 바이너리 항목에서 찾을 수 있는 윈도우에서 실행되는 `kubectl`을 선택적으로 다운로드 받을 수 있다.
|
||||
|
||||
압축 파일을 풀고, `C:\k`로 바이너리를 위치하기 위해 [Expand-Archive](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.archive/expand-archive?view=powershell-6) 파워쉘 커맨드를 이용할 수 있다.
|
||||
|
||||
#### 윈도우 노드를 플라넬 클러스터에 가입하기
|
||||
|
||||
플라넬 오버레이 배포 스크립트와 문서는 [이 리포지터리](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/overlay)에 있다. 다음 단계는 그곳에 있는 자세한 요령을 따라서 단순히 진행하는 것이다.
|
||||
|
||||
[Flannel start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1) 스크립트를 다운로드받고, 그 내용을 `C:\k`에 풀어 넣자.
|
||||
|
||||
```PowerShell
|
||||
cd c:\k
|
||||
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
|
||||
wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/start.ps1 -o c:\k\start.ps1
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
[start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1)은 [install.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/install.ps1)을 참고하는데, 이는 사용자를 위해 `flanneld` 실행 **파일 같은** 추가 파일과 [인프라스트럭처 파드를 위한 Dockerfile](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/Dockerfile)을 다운로드하고 설치한다. 오버레이 네트워킹 방식에서 [방화벽](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/helper.psm1#L111)은 지역 UDP 4789 포트에 대해 열려있다. 여러 파워쉘 윈도우가 열렸다 닫히며, 포드 네트워크를 위한 새로운 외부 vSwitch가 처음 생성되는 동안 몇 초간은 네트워크가 중단된다. 아래 지정한 인수를 사용하여 스크립트를 실행하자.
|
||||
{{< /note >}}
|
||||
|
||||
```PowerShell
|
||||
.\start.ps1 -ManagementIP <Windows Node IP> -NetworkMode overlay -ClusterCIDR <Cluster CIDR> -ServiceCIDR <Service CIDR> -KubeDnsServiceIP <Kube-dns Service IP> -LogDir <Log directory>
|
||||
```
|
||||
|
||||
| 파라미터 | 기본값 | 비고 |
|
||||
| --- | --- | --- |
|
||||
| -ManagementIP | N/A (필요함) | 윈도우 노드에 할당할 IP 주소. 이 값을 찾기 위해 `ipconfig` 이용할 수 있다. |
|
||||
| -NetworkMode | l2bridge | 여기서는 `overlay`를 사용한다. |
|
||||
| -ClusterCIDR | 10.244.0.0/16 | 클러스터 IP 설계을 참고한다. |
|
||||
| -ServiceCIDR | 10.96.0.0/12 | 클러스터 IP 설계을 참고한다. |
|
||||
| -KubeDnsServiceIP | 10.96.0.10 | |
|
||||
| -InterfaceName | Ethernet | 윈도우 호스트의 네트워크 인터페이스 이름. 이 값을 찾기 위해 <code>ipconfig</code> 이용할 수 있다. |
|
||||
| -LogDir | C:\k | Kubelet과 Kube-proxy가 각각의 로그 출력 파일을 리다이렉션하는 디렉터리이다. |
|
||||
|
||||
이제 다음을 실행하여 사용자 클러스터 내에 윈도우 노드를 볼 수 있다.
|
||||
|
||||
```bash
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Kubelet, kueb-proxy 같은 윈도우 노드 구성요소를 윈도우 서비스로 구성할 수 있다. 추가적인 방법은 [문제 해결](#troubleshooting)의 서비스와 백그라운드 프로세스 단원을 보자. 노드의 구성요소를 서비스로 실행하면 로그 수집하는 것이 문제 해결에 있어 중요한 부분이 된다. 추가 지침으로 기여 가이드에서 [로그 수집하기](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) 단원을 보자.
|
||||
{{< /note >}}
|
||||
|
||||
### 공개 클라우드 제공자
|
||||
|
||||
#### Azure
|
||||
|
||||
AKS-Engine은 완전하고, 맞춤 설정이 가능한 쿠버네티스 클러스터를 리눅스와 윈도우 노드에 배포할 수 있다. 단계별 안내가 [GitHub에 있는 문서](https://github.com/Azure/aks-engine/blob/master/docs/topics/windows.md)로 제공된다.
|
||||
|
||||
#### GCP
|
||||
|
||||
사용자가 [GitHub](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/windows/README-GCE-Windows-kube-up.md)에 있는 단계별 안내를 따라서 완전한 쿠버네티스 클러스터를 GCE 상에 쉽게 배포할 수 있다.
|
||||
|
||||
#### kubeadm과 클러스터 API로 배포하기
|
||||
|
||||
Kubeadm은 쿠버네티스 클러스터를 배포하는 사용자에게 산업 표준이 되었다. Kubeadm에서 윈도우 노드 지원은 미래 릴리스에 나올 것이다. 또한 윈도우 노드가 올바르게 프로비저닝되도록 클러스터 API에 투자하고 있다.
|
||||
|
||||
### 다음 단계
|
||||
|
||||
이제 클러스터 내에 윈도우 컨테이너를 실행하도록 윈도우 워커를 구성했으니, 리눅스 컨테이너를 실행할 리눅스 노드를 1개 이상 추가할 수 있다. 이제 윈도우 컨테이너를 클러스터에 스케줄링할 준비가 됬다.
|
||||
|
||||
{{% /capture %}}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 80 KiB |
Reference in New Issue
Block a user