Forth Korean l10n work for release-1.19
- Fix ko glossary managed service title (#24621) - Translate reference/glossary/service-broker.md in Korean (#24632) - Translate reference/command-line-tools-reference/kubelet-authentication-authorization.md into korean (#24623) - Update outdated files in the dev-1.19-ko.4 branch (#24622) - Translate setup/production-environment/tools/kubeadm/self-hosting/ into Korean (#24655) - Translate reference/kubectl/kubectl.md into Korean (#24482) - docs: fix typo (#24713) - Translate connecting-frontend-backend to Korean (#24422) - Translate reference/kubectl/conventions.md into Korean (#24614) - Translate k8s 1.19 relaese note in korean (#24633) Co-authored-by: seokho-son <shsongist@gmail.com> Co-authored-by: santachopa <santachopa@naver.com> Co-authored-by: kosehy@gmail.com <kosehy@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: markruler <csu0414@gmail.com> Co-authored-by: noel <neutiyoo@gmail.com> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: chhanz <han0495@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com>
This commit is contained in:
Jerry Park
@@ -1,398 +1,140 @@
|
||||
---
|
||||
title: 여러 영역에서 구동
|
||||
weight: 10
|
||||
title: 여러 영역에서 실행
|
||||
weight: 20
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 여러 영역에서 어떻게 클러스터를 구동하는지 설명한다.
|
||||
|
||||
|
||||
이 페이지에서는 여러 영역에서 쿠버네티스를 실행하는 방법을 설명한다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 소개
|
||||
## 배경
|
||||
|
||||
Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
|
||||
(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
|
||||
This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
|
||||
nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)).
|
||||
Full Cluster Federation allows combining separate
|
||||
Kubernetes clusters running in different regions or cloud providers
|
||||
(or on-premises data centers). However, many
|
||||
users simply want to run a more available Kubernetes cluster in multiple zones
|
||||
of their single cloud provider, and this is what the multizone support in 1.2 allows
|
||||
(this previously went by the nickname "Ubernetes Lite").
|
||||
쿠버네티스는 단일 쿠버네티스 클러스터가 여러 장애 영역에서
|
||||
실행될 수 있도록 설계되었다. 일반적으로 이러한 영역은 _지역(region)_ 이라는
|
||||
논리적 그룹 내에 적합하다. 주요 클라우드 제공자는 지역을 일관된 기능 집합을
|
||||
제공하는 장애 영역 집합(_가용성 영역_ 이라고도 함)으로
|
||||
정의한다. 지역 내에서 각 영역은 동일한 API 및
|
||||
서비스를 제공한다.
|
||||
|
||||
Multizone support is deliberately limited: a single Kubernetes cluster can run
|
||||
in multiple zones, but only within the same region (and cloud provider). Only
|
||||
GCE and AWS are currently supported automatically (though it is easy to
|
||||
add similar support for other clouds or even bare metal, by simply arranging
|
||||
for the appropriate labels to be added to nodes and volumes).
|
||||
일반적인 클라우드 아키텍처는 한 영역의 장애가 다른 영역의 서비스도
|
||||
손상시킬 가능성을 최소화하는 것을 목표로 한다.
|
||||
|
||||
## 컨트롤 플레인 동작
|
||||
|
||||
## 기능
|
||||
모든 [컨트롤 플레인 컴포넌트](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)는
|
||||
컴포넌트별로 복제되는 교환 가능한 리소스 풀로 실행을
|
||||
지원한다.
|
||||
|
||||
When nodes are started, the kubelet automatically adds labels to them with
|
||||
zone information.
|
||||
|
||||
Kubernetes will automatically spread the pods in a replication controller
|
||||
or service across nodes in a single-zone cluster (to reduce the impact of
|
||||
failures.) With multiple-zone clusters, this spreading behavior is
|
||||
extended across zones (to reduce the impact of zone failures.) (This is
|
||||
achieved via `SelectorSpreadPriority`). This is a best-effort
|
||||
placement, and so if the zones in your cluster are heterogeneous
|
||||
(e.g. different numbers of nodes, different types of nodes, or
|
||||
different pod resource requirements), this might prevent perfectly
|
||||
even spreading of your pods across zones. If desired, you can use
|
||||
homogeneous zones (same number and types of nodes) to reduce the
|
||||
probability of unequal spreading.
|
||||
|
||||
When persistent volumes are created, the `PersistentVolumeLabel`
|
||||
admission controller automatically adds zone labels to them. The scheduler (via the
|
||||
`VolumeZonePredicate` predicate) will then ensure that pods that claim a
|
||||
given volume are only placed into the same zone as that volume, as volumes
|
||||
cannot be attached across zones.
|
||||
|
||||
## 제한 사항
|
||||
|
||||
There are some important limitations of the multizone support:
|
||||
|
||||
* We assume that the different zones are located close to each other in the
|
||||
network, so we don't perform any zone-aware routing. In particular, traffic
|
||||
that goes via services might cross zones (even if some pods backing that service
|
||||
exist in the same zone as the client), and this may incur additional latency and cost.
|
||||
|
||||
* Volume zone-affinity will only work with a `PersistentVolume`, and will not
|
||||
work if you directly specify an EBS volume in the pod spec (for example).
|
||||
|
||||
* Clusters cannot span clouds or regions (this functionality will require full
|
||||
federation support).
|
||||
|
||||
* Although your nodes are in multiple zones, kube-up currently builds
|
||||
a single master node by default. While services are highly
|
||||
available and can tolerate the loss of a zone, the control plane is
|
||||
located in a single zone. Users that want a highly available control
|
||||
plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions.
|
||||
|
||||
### Volume limitations
|
||||
The following limitations are addressed with [topology-aware volume binding](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드).
|
||||
|
||||
* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with
|
||||
pod affinity or anti-affinity policies.
|
||||
|
||||
* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
|
||||
may not provide a uniform distribution of storage across zones.
|
||||
|
||||
* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
|
||||
needs to be configured for a specific single zone, or the PVs need to be
|
||||
statically provisioned in a specific zone. Another workaround is to use a
|
||||
StatefulSet, which will ensure that all the volumes for a replica are
|
||||
provisioned in the same zone.
|
||||
|
||||
## 연습
|
||||
|
||||
We're now going to walk through setting up and using a multi-zone
|
||||
cluster on both GCE & AWS. To do so, you bring up a full cluster
|
||||
(specifying `MULTIZONE=true`), and then you add nodes in additional zones
|
||||
by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`).
|
||||
|
||||
### 클러스터 가져오기
|
||||
|
||||
Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a.
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash
|
||||
```
|
||||
|
||||
AWS:
|
||||
|
||||
```shell
|
||||
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
|
||||
```
|
||||
|
||||
This step brings up a cluster as normal, still running in a single zone
|
||||
(but `MULTIZONE=true` has enabled multi-zone capabilities).
|
||||
|
||||
### 라벨이 지정된 노드 확인
|
||||
|
||||
View the nodes; you can see that they are labeled with zone information.
|
||||
They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far. The
|
||||
labels are `failure-domain.beta.kubernetes.io/region` for the region,
|
||||
and `failure-domain.beta.kubernetes.io/zone` for the zone:
|
||||
|
||||
```shell
|
||||
kubectl get nodes --show-labels
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
NAME STATUS ROLES AGE VERSION LABELS
|
||||
kubernetes-master Ready,SchedulingDisabled <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
|
||||
kubernetes-minion-87j9 Ready <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
|
||||
kubernetes-minion-9vlv Ready <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
kubernetes-minion-a12q Ready <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
|
||||
```
|
||||
|
||||
### 두번째 영역에 더 많은 노드 추가하기
|
||||
|
||||
Let's add another set of nodes to the existing cluster, reusing the
|
||||
existing master, running in a different zone (us-central1-b or us-west-2b).
|
||||
We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true`
|
||||
kube-up will not create a new master, but will reuse one that was previously
|
||||
created instead.
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
On AWS we also need to specify the network CIDR for the additional
|
||||
subnet, along with the master internal IP address:
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
|
||||
View the nodes again; 3 more nodes should have launched and be tagged
|
||||
in us-central1-b:
|
||||
|
||||
```shell
|
||||
kubectl get nodes --show-labels
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
NAME STATUS ROLES AGE VERSION LABELS
|
||||
kubernetes-master Ready,SchedulingDisabled <none> 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
|
||||
kubernetes-minion-281d Ready <none> 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
|
||||
kubernetes-minion-87j9 Ready <none> 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
|
||||
kubernetes-minion-9vlv Ready <none> 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
kubernetes-minion-a12q Ready <none> 17m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
|
||||
kubernetes-minion-pp2f Ready <none> 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
|
||||
kubernetes-minion-wf8i Ready <none> 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
|
||||
```
|
||||
|
||||
### 볼륨 어피니티
|
||||
|
||||
Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
|
||||
|
||||
```bash
|
||||
kubectl apply -f - <<EOF
|
||||
{
|
||||
"apiVersion": "v1",
|
||||
"kind": "PersistentVolumeClaim",
|
||||
"metadata": {
|
||||
"name": "claim1",
|
||||
"annotations": {
|
||||
"volume.alpha.kubernetes.io/storage-class": "foo"
|
||||
}
|
||||
},
|
||||
"spec": {
|
||||
"accessModes": [
|
||||
"ReadWriteOnce"
|
||||
],
|
||||
"resources": {
|
||||
"requests": {
|
||||
"storage": "5Gi"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
EOF
|
||||
```
|
||||
클러스터 컨트롤 플레인을 배포할 때, 여러 장애 영역에
|
||||
컨트롤 플레인 컴포넌트의 복제본을 배치한다. 가용성이
|
||||
중요한 문제인 경우, 3개 이상의 장애 영역을 선택하고
|
||||
각 개별 컨트롤 플레인 컴포넌트(API 서버, 스케줄러, etcd,
|
||||
클러스터 컨트롤러 관리자)를 3개 이상의 장애 영역에 복제한다.
|
||||
클라우드 컨트롤러 관리자를 실행 중인 경우 선택한
|
||||
모든 장애 영역에 걸쳐 이를 복제해야 한다.
|
||||
|
||||
{{< note >}}
|
||||
For version 1.3+ Kubernetes will distribute dynamic PV claims across
|
||||
the configured zones. For version 1.2, dynamic persistent volumes were
|
||||
always created in the zone of the cluster master
|
||||
(here us-central1-a / us-west-2a); that issue
|
||||
([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
|
||||
was addressed in 1.3+.
|
||||
쿠버네티스는 API 서버 엔드포인트에 대한 교차 영역 복원성을 제공하지
|
||||
않는다. DNS 라운드-로빈, SRV 레코드 또는 상태 확인 기능이 있는
|
||||
써드파티 로드 밸런싱 솔루션을 포함하여 다양한 기술을 사용하여
|
||||
클러스터 API 서버의 가용성을 향상시킬 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in.
|
||||
## 노드 동작
|
||||
|
||||
```shell
|
||||
kubectl get pv --show-labels
|
||||
```
|
||||
쿠버네티스는 클러스터의 여러 노드에 걸쳐
|
||||
워크로드 리소스(예: {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}}
|
||||
또는 {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}})에
|
||||
대한 파드를 자동으로 분배한다. 이러한 분배는
|
||||
실패에 대한 영향을 줄이는 데 도움이 된다.
|
||||
|
||||
The output is similar to this:
|
||||
노드가 시작되면, 각 노드의 kubelet이 쿠버네티스 API에서
|
||||
특정 kubelet을 나타내는 노드 오브젝트에
|
||||
{{< glossary_tooltip text="레이블" term_id="label" >}}을 자동으로 추가한다.
|
||||
이러한 레이블에는
|
||||
[영역 정보](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다.
|
||||
|
||||
```shell
|
||||
NAME CAPACITY ACCESSMODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE LABELS
|
||||
pv-gce-mj4gm 5Gi RWO Retain Bound default/claim1 manual 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
|
||||
```
|
||||
클러스터가 여러 영역 또는 지역에 걸쳐있는 경우,
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)과
|
||||
함께 노드 레이블을 사용하여
|
||||
파드가 장애 도메인(지역, 영역, 특정 노드) 간 클러스터에
|
||||
분산되는 방식을 제어할 수 있다.
|
||||
이러한 힌트를 통해
|
||||
{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}는
|
||||
더 나은 예상 가용성을 위해 파드를 배치할 수 있으므로, 상관 관계가 있는
|
||||
오류가 전체 워크로드에 영향을 미칠 위험을 줄일 수 있다.
|
||||
|
||||
So now we will create a pod that uses the persistent volume claim.
|
||||
Because GCE PDs / AWS EBS volumes cannot be attached across zones,
|
||||
this means that this pod can only be created in the same zone as the volume:
|
||||
예를 들어, 가능할 때마다 스테이트풀셋의
|
||||
3개 복제본이 모두 서로 다른 영역에서 실행되도록 제약 조건을
|
||||
설정할 수 있다. 각 워크로드에 사용 중인
|
||||
가용 영역을 명시적으로 정의하지 않고 이를 선언적으로
|
||||
정의할 수 있다.
|
||||
|
||||
```yaml
|
||||
kubectl apply -f - <<EOF
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
containers:
|
||||
- name: myfrontend
|
||||
image: nginx
|
||||
volumeMounts:
|
||||
- mountPath: "/var/www/html"
|
||||
name: mypd
|
||||
volumes:
|
||||
- name: mypd
|
||||
persistentVolumeClaim:
|
||||
claimName: claim1
|
||||
EOF
|
||||
```
|
||||
### 여러 영역에 노드 분배
|
||||
|
||||
Note that the pod was automatically created in the same zone as the volume, as
|
||||
cross-zone attachments are not generally permitted by cloud providers:
|
||||
쿠버네티스의 코어는 사용자를 위해 노드를 생성하지 않는다. 사용자가 직접 수행하거나,
|
||||
[클러스터 API](https://cluster-api.sigs.k8s.io/)와 같은 도구를 사용하여
|
||||
사용자 대신 노드를 관리해야 한다.
|
||||
|
||||
```shell
|
||||
kubectl describe pod mypod | grep Node
|
||||
```
|
||||
클러스터 API와 같은 도구를 사용하면 여러 장애 도메인에서
|
||||
클러스터의 워커 노드로 실행할 머신 집합과 전체 영역 서비스 중단 시
|
||||
클러스터를 자동으로 복구하는 규칙을 정의할 수 있다.
|
||||
|
||||
```shell
|
||||
Node: kubernetes-minion-9vlv/10.240.0.5
|
||||
```
|
||||
## 파드에 대한 수동 영역 할당
|
||||
|
||||
And check node labels:
|
||||
생성한 파드와 디플로이먼트, 스테이트풀셋, 잡(Job)과
|
||||
같은 워크로드 리소스의 파드 템플릿에 [노드 셀렉터 제약 조건](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)을
|
||||
적용할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get node kubernetes-minion-9vlv --show-labels
|
||||
```
|
||||
## 영역에 대한 스토리지 접근
|
||||
|
||||
```shell
|
||||
NAME STATUS AGE VERSION LABELS
|
||||
kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
```
|
||||
퍼시스턴트 볼륨이 생성되면, `PersistentVolumeLabel`
|
||||
[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)는
|
||||
특정 영역에 연결된 모든 퍼시스턴트볼륨(PersistentVolume)에 영역 레이블을 자동으로
|
||||
추가한다. 그런 다음 {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}는
|
||||
`NoVolumeZoneConflict` 프레디케이트(predicate)를 통해 주어진 퍼시스턴트볼륨을 요구하는 파드가
|
||||
해당 볼륨과 동일한 영역에만 배치되도록 한다.
|
||||
|
||||
### 여러 영역에 파드 분배하기
|
||||
해당 클래스의 스토리지가 사용할 수 있는 장애 도메인(영역)을 지정하는
|
||||
퍼시스턴트볼륨클레임(PersistentVolumeClaims)에 대한
|
||||
{{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 지정할 수 있다.
|
||||
장애 도메인 또는 영역을 인식하는 스토리지클래스 구성에 대한 자세한 내용은
|
||||
[허용된 토폴로지](/ko/docs/concepts/storage/storage-classes/#허용된-토폴로지)를 참고한다.
|
||||
|
||||
Pods in a replication controller or service are automatically spread
|
||||
across zones. First, let's launch more nodes in a third zone:
|
||||
## 네트워킹
|
||||
|
||||
GCE:
|
||||
쿠버네티스가 스스로 영역-인지(zone-aware) 네트워킹을 포함하지는 않는다.
|
||||
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을
|
||||
사용하여 클러스터 네트워킹을 구성할 수 있으며, 해당 네트워크 솔루션에는 영역별 요소가
|
||||
있을 수 있다. 예를 들어, 클라우드 제공자가
|
||||
`type=LoadBalancer` 를 사용하여 서비스를 지원하는 경우, 로드 밸런서는 지정된 연결을 처리하는
|
||||
로드 밸런서 요소와 동일한 영역에서 실행 중인 파드로만 트래픽을 보낼 수 있다.
|
||||
자세한 내용은 클라우드 제공자의 문서를 확인한다.
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
사용자 정의 또는 온-프레미스 배포의 경우, 비슷한 고려 사항이 적용된다.
|
||||
다른 장애 영역 처리를 포함한 {{< glossary_tooltip text="서비스" term_id="service" >}}와
|
||||
{{< glossary_tooltip text="인그레스(Ingress)" term_id="ingress" >}} 동작은
|
||||
클러스터가 설정된 방식에 명확히 의존한다.
|
||||
|
||||
AWS:
|
||||
## 장애 복구
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
클러스터를 설정할 때, 한 지역의 모든 장애 영역이 동시에
|
||||
오프라인 상태가 되는 경우 설정에서 서비스를 복원할 수 있는지
|
||||
여부와 방법을 고려해야 할 수도 있다. 예를 들어, 영역에서 파드를 실행할 수 있는
|
||||
노드가 적어도 하나 이상 있어야 하는가?
|
||||
클러스터에 중요한 복구 작업이 클러스터에
|
||||
적어도 하나 이상의 정상 노드에 의존하지 않는지 확인한다. 예를 들어, 모든 노드가
|
||||
비정상인 경우, 하나 이상의 노드를 서비스할 수 있을 만큼 복구를 완료할 수 있도록 특별한
|
||||
{{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}으로
|
||||
복구 작업을 실행해야 할 수 있다.
|
||||
|
||||
Verify that you now have nodes in 3 zones:
|
||||
쿠버네티스는 이 문제에 대한 답을 제공하지 않는다. 그러나,
|
||||
고려해야 할 사항이다.
|
||||
|
||||
```shell
|
||||
kubectl get nodes --show-labels
|
||||
```
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
|
||||
|
||||
```shell
|
||||
find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
|
||||
```
|
||||
|
||||
The pods should be spread across all 3 zones:
|
||||
|
||||
```shell
|
||||
kubectl describe pod -l app=guestbook | grep Node
|
||||
```
|
||||
|
||||
```shell
|
||||
Node: kubernetes-minion-9vlv/10.240.0.5
|
||||
Node: kubernetes-minion-281d/10.240.0.8
|
||||
Node: kubernetes-minion-olsh/10.240.0.11
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels
|
||||
```
|
||||
|
||||
```shell
|
||||
NAME STATUS ROLES AGE VERSION LABELS
|
||||
kubernetes-minion-9vlv Ready <none> 34m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
kubernetes-minion-281d Ready <none> 20m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
|
||||
kubernetes-minion-olsh Ready <none> 3m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
|
||||
```
|
||||
|
||||
|
||||
Load-balancers span all zones in a cluster; the guestbook-go example
|
||||
includes an example load-balanced service:
|
||||
|
||||
```shell
|
||||
kubectl describe service guestbook | grep LoadBalancer.Ingress
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
LoadBalancer Ingress: 130.211.126.21
|
||||
```
|
||||
|
||||
Set the above IP:
|
||||
|
||||
```shell
|
||||
export IP=130.211.126.21
|
||||
```
|
||||
|
||||
Explore with curl via IP:
|
||||
|
||||
```shell
|
||||
curl -s http://${IP}:3000/env | grep HOSTNAME
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
"HOSTNAME": "guestbook-44sep",
|
||||
```
|
||||
|
||||
Again, explore multiple times:
|
||||
|
||||
```shell
|
||||
(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done) | sort | uniq
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
"HOSTNAME": "guestbook-44sep",
|
||||
"HOSTNAME": "guestbook-hum5n",
|
||||
"HOSTNAME": "guestbook-ppm40",
|
||||
```
|
||||
|
||||
The load balancer correctly targets all the pods, even though they are in multiple zones.
|
||||
|
||||
### 클러스터 강제 종료
|
||||
|
||||
When you're done, clean up:
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh
|
||||
```
|
||||
|
||||
AWS:
|
||||
|
||||
```shell
|
||||
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
|
||||
```
|
||||
스케줄러가 구성된 제약 조건을 준수하면서, 클러스터에 파드를 배치하는 방법을 알아보려면,
|
||||
[스케줄링과 축출(eviction)](/ko/docs/concepts/scheduling-eviction/)을 참고한다.
|
||||
|
||||
@@ -29,9 +29,6 @@ weight: 10
|
||||
다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
|
||||
{{< /note >}}
|
||||
|
||||
이 가이드의 모든 명령은 `root`로 실행해야 한다.
|
||||
예를 들어,`sudo`로 접두사를 붙이거나, `root` 사용자가 되어 명령을 실행한다.
|
||||
|
||||
### Cgroup 드라이버
|
||||
|
||||
리눅스 배포판의 init 시스템이 systemd인 경우, init 프로세스는
|
||||
@@ -74,18 +71,18 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다.
|
||||
# (도커 CE 설치)
|
||||
## 리포지터리 설정
|
||||
### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치
|
||||
apt-get update && apt-get install -y \
|
||||
sudo apt-get update && sudo apt-get install -y \
|
||||
apt-transport-https ca-certificates curl software-properties-common gnupg2
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 공식 GPG 키 추가
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 apt 리포지터리 추가.
|
||||
add-apt-repository \
|
||||
sudo add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
@@ -93,7 +90,7 @@ add-apt-repository \
|
||||
|
||||
```shell
|
||||
# 도커 CE 설치.
|
||||
apt-get update && apt-get install -y \
|
||||
sudo apt-get update && sudo apt-get install -y \
|
||||
containerd.io=1.2.13-2 \
|
||||
docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
|
||||
docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
|
||||
@@ -101,7 +98,7 @@ apt-get update && apt-get install -y \
|
||||
|
||||
```shell
|
||||
# 도커 데몬 설정
|
||||
cat > /etc/docker/daemon.json <<EOF
|
||||
cat <<EOF | sudo tee /etc/docker/daemon.json
|
||||
{
|
||||
"exec-opts": ["native.cgroupdriver=systemd"],
|
||||
"log-driver": "json-file",
|
||||
@@ -114,13 +111,13 @@ EOF
|
||||
```
|
||||
|
||||
```shell
|
||||
mkdir -p /etc/systemd/system/docker.service.d
|
||||
sudo mkdir -p /etc/systemd/system/docker.service.d
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 재시작.
|
||||
systemctl daemon-reload
|
||||
systemctl restart docker
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS/RHEL 7.4+" %}}
|
||||
@@ -129,18 +126,18 @@ systemctl restart docker
|
||||
# (도커 CE 설치)
|
||||
## 리포지터리 설정
|
||||
### 필요한 패키지 설치
|
||||
yum install -y yum-utils device-mapper-persistent-data lvm2
|
||||
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
|
||||
```
|
||||
|
||||
```shell
|
||||
## 도커 리포지터리 추가
|
||||
yum-config-manager --add-repo \
|
||||
sudo yum-config-manager --add-repo \
|
||||
https://download.docker.com/linux/centos/docker-ce.repo
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 CE 설치.
|
||||
yum update -y && yum install -y \
|
||||
sudo yum update -y && sudo yum install -y \
|
||||
containerd.io-1.2.13 \
|
||||
docker-ce-19.03.11 \
|
||||
docker-ce-cli-19.03.11
|
||||
@@ -148,12 +145,12 @@ yum update -y && yum install -y \
|
||||
|
||||
```shell
|
||||
## /etc/docker 생성.
|
||||
mkdir /etc/docker
|
||||
sudo mkdir /etc/docker
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 데몬 설정.
|
||||
cat > /etc/docker/daemon.json <<EOF
|
||||
cat <<EOF | sudo tee /etc/docker/daemon.json
|
||||
{
|
||||
"exec-opts": ["native.cgroupdriver=systemd"],
|
||||
"log-driver": "json-file",
|
||||
@@ -169,13 +166,13 @@ EOF
|
||||
```
|
||||
|
||||
```shell
|
||||
mkdir -p /etc/systemd/system/docker.service.d
|
||||
sudo mkdir -p /etc/systemd/system/docker.service.d
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 재시작.
|
||||
systemctl daemon-reload
|
||||
systemctl restart docker
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
@@ -203,17 +200,17 @@ CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너
|
||||
### 선행 조건
|
||||
|
||||
```shell
|
||||
modprobe overlay
|
||||
modprobe br_netfilter
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅 간에도 유지된다.
|
||||
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
sysctl --system
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
{{< tabs name="tab-cri-cri-o-installation" >}}
|
||||
@@ -235,16 +232,19 @@ sysctl --system
|
||||
|
||||
그런 다음, 아래를 실행한다.
|
||||
```shell
|
||||
echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
"deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /"
|
||||
EOF
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
|
||||
"deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /"
|
||||
EOF
|
||||
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add -
|
||||
|
||||
apt-get update
|
||||
apt-get install cri-o cri-o-runc
|
||||
sudo apt-get update
|
||||
sudo apt-get install cri-o cri-o-runc
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Ubuntu" %}}
|
||||
@@ -297,9 +297,9 @@ apt-get install cri-o cri-o-runc
|
||||
|
||||
그런 다음, 아래를 실행한다.
|
||||
```shell
|
||||
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
|
||||
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
|
||||
yum install cri-o
|
||||
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
|
||||
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
|
||||
sudo yum install cri-o
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
@@ -317,14 +317,14 @@ sudo zypper install cri-o
|
||||
|
||||
사용할 수 있는 버전을 찾으려면 다음을 실행한다.
|
||||
```shell
|
||||
dnf module list cri-o
|
||||
sudo dnf module list cri-o
|
||||
```
|
||||
CRI-O는 Fedora에서 특정 릴리스를 고정하여 설치하는 방법은 지원하지 않는다.
|
||||
|
||||
그런 다음, 아래를 실행한다.
|
||||
```shell
|
||||
dnf module enable cri-o:$VERSION
|
||||
dnf install cri-o
|
||||
sudo dnf module enable cri-o:$VERSION
|
||||
sudo dnf install cri-o
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
@@ -333,8 +333,8 @@ dnf install cri-o
|
||||
### CRI-O 시작
|
||||
|
||||
```shell
|
||||
systemctl daemon-reload
|
||||
systemctl start crio
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl start crio
|
||||
```
|
||||
|
||||
자세한 사항은 [CRI-O 설치 가이드](https://github.com/kubernetes-sigs/cri-o#getting-started)를
|
||||
@@ -349,22 +349,22 @@ Containerd를 시스템에 설치하기 위해서 다음의 커맨드들을 사
|
||||
### 선행 조건
|
||||
|
||||
```shell
|
||||
cat > /etc/modules-load.d/containerd.conf <<EOF
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
modprobe overlay
|
||||
modprobe br_netfilter
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅에서도 유지된다.
|
||||
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
sysctl --system
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
### containerd 설치
|
||||
@@ -376,17 +376,17 @@ sysctl --system
|
||||
# (containerd 설치)
|
||||
## 리포지터리 설정
|
||||
### apt가 HTTPS로 리포지터리를 사용하는 것을 허용하기 위한 패키지 설치
|
||||
apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
|
||||
```
|
||||
|
||||
```shell
|
||||
## 도커 공식 GPG 키 추가
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
|
||||
```
|
||||
|
||||
```shell
|
||||
## 도커 apt 리포지터리 추가.
|
||||
add-apt-repository \
|
||||
sudo add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
@@ -394,18 +394,18 @@ add-apt-repository \
|
||||
|
||||
```shell
|
||||
## containerd 설치
|
||||
apt-get update && apt-get install -y containerd.io
|
||||
sudo apt-get update && sudo apt-get install -y containerd.io
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 설정
|
||||
mkdir -p /etc/containerd
|
||||
containerd config default > /etc/containerd/config.toml
|
||||
sudo mkdir -p /etc/containerd
|
||||
sudo containerd config default > /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 재시작
|
||||
systemctl restart containerd
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS/RHEL 7.4+" %}}
|
||||
@@ -414,30 +414,30 @@ systemctl restart containerd
|
||||
# (containerd 설치)
|
||||
## 리포지터리 설정
|
||||
### 필요한 패키지 설치
|
||||
yum install -y yum-utils device-mapper-persistent-data lvm2
|
||||
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
|
||||
```
|
||||
|
||||
```shell
|
||||
## 도커 리포지터리 추가
|
||||
yum-config-manager \
|
||||
sudo yum-config-manager \
|
||||
--add-repo \
|
||||
https://download.docker.com/linux/centos/docker-ce.repo
|
||||
```
|
||||
|
||||
```shell
|
||||
## containerd 설치
|
||||
yum update -y && yum install -y containerd.io
|
||||
sudo yum update -y && yum install -y containerd.io
|
||||
```
|
||||
|
||||
```shell
|
||||
## containerd 설정
|
||||
mkdir -p /etc/containerd
|
||||
containerd config default > /etc/containerd/config.toml
|
||||
sudo mkdir -p /etc/containerd
|
||||
sudo containerd config default > /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 재시작
|
||||
systemctl restart containerd
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="윈도우 (PowerShell)" %}}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
---
|
||||
title: Installing Kubernetes with deployment tools
|
||||
title: 배포 도구로 쿠버네티스 설치하기
|
||||
weight: 30
|
||||
---
|
||||
|
||||
@@ -198,7 +198,7 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의
|
||||
|
||||
만약 kops사용이 처음이라면, 얼마 걸리지 않으니 이들을 시험해 본다. 인스턴스 그룹은
|
||||
쿠버네티스 노드로 등록된 인스턴스의 집합을 말한다. AWS상에서는 auto-scaling-groups를
|
||||
통해 만들어진다. 사용자는 여러개의 인스턴스 그룹을 관리할 수 있는데,
|
||||
통해 만들어진다. 사용자는 여러 개의 인스턴스 그룹을 관리할 수 있는데,
|
||||
예를 들어, spot과 on-demand 인스턴스 조합 또는 GPU 와 non-GPU 인스턴스의 조합으로 구성할 수 있다.
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 컨트롤 플레인을 자체 호스팅하기 위해 쿠버네티스 클러스터 구성하기
|
||||
content_type: concept
|
||||
weight: 100
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
### 쿠버네티스 컨트롤 플레인 자체 호스팅하기 {#self-hosting}
|
||||
|
||||
kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플레인을 만들 수 있도록
|
||||
해준다. API 서버, 컨트롤러 매니저 및 스케줄러와 같은 주요 구성 요소가 정적(static) 파일을
|
||||
통해 kubelet에 구성된 [스태틱(static) 파드](/docs/tasks/configure-pod-container/static-pod/)
|
||||
대신 쿠버네티스 API를 통해 구성된 [데몬셋(DaemonSet) 파드](/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`](/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. 기존의 컨트롤 플레인이 멈추면 새롭게 자체 호스팅된 컨트롤 플레인은
|
||||
리스닝 포트에 바인딩하여 활성화할 수 있다.
|
||||
|
||||
|
||||
@@ -259,7 +259,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
|
||||
|
||||
오버 프로비저닝을 방지하는 모범 사례는 윈도우, 도커 및 쿠버네티스 프로세스를 고려하여 최소 2GB의 시스템 예약 메모리로 kubelet을 구성하는 것이다.
|
||||
|
||||
플래그의 동작은 아래에 설명된대로 다르게 동작한다.
|
||||
플래그의 동작은 아래에 설명된 대로 다르게 동작한다.
|
||||
|
||||
* `--kubelet-reserve`, `--system-reserve`, `--eviction-hard` 플래그는 Node Allocatable 업데이트
|
||||
* `--enforce-node-allocable`을 사용한 축출(Eviction)은 구현되지 않았다.
|
||||
@@ -570,7 +570,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
|
||||
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
|
||||
```
|
||||
|
||||
호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, 종종 start.ps1 스크립트의 [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L6) 파라미터를 수정하는 것이 좋다. 그렇지 않으면 `start-kubelet.ps1` 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다.
|
||||
호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, 종종 start.ps1 스크립트의 [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) 파라미터를 수정하는 것이 좋다. 그렇지 않으면 `start-kubelet.ps1` 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다.
|
||||
|
||||
1. 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다.
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user