First Korean l10n work for release-1.15 (#15356)
* Translate concepts/workloads/controllers/replicationcontroller in Korean (#15044) * ko: Update outdated 1.14-ko.4 branch (#15099) * Translate tasks/access-application-cluster/configure-access-multiple-clusters in Korean (#15121) * Translate standardized glossary items in Tag Network into Korean (#15278) * ko: Keep up with upstream - renamed files (#15030) Co-Authored-By: Seokho <shsongist@gmail.com> Co-Authored-By: lapee79 <lapee79@gmail.com> Co-Authored-By: Yoon <learder@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com>
This commit is contained in:
June Yi
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
bdf4e5fef6
commit
113008ff6e
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: 운영 환경
|
||||
weight: 30
|
||||
---
|
||||
@@ -0,0 +1,291 @@
|
||||
---
|
||||
title: 컨테이너 런타임
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
{{% capture overview %}}
|
||||
{{< feature-state for_k8s_version="v1.6" state="stable" >}}
|
||||
파드에서 컨테이너를 실행하기 위해 쿠버네티스는 컨테이너 런타임을 사용한다.
|
||||
이 페이지는 다양한 런타임들에 대한 설치 지침을 담고 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
{{< caution >}}
|
||||
컨테이너를 실행할 때 runc가 시스템 파일 디스크립터를 처리하는 방식에서 결함이 발견되었다.
|
||||
악성 컨테이너는 이 결함을 사용하여 runc 바이너리의 내용을 덮어쓸 수 있으며
|
||||
따라서 컨테이너 호스트 시스템에서 임의의 명령을 실행할 수 있다.
|
||||
|
||||
이 문제에 대한 자세한 내용은
|
||||
[cve-2019-5736 : runc 취약점 ] (https://access.redhat.com/security/cve/cve-2019-5736) 참고하자.
|
||||
{{< /caution >}}
|
||||
|
||||
### 적용 가능성
|
||||
|
||||
{{< note >}}
|
||||
이 문서는 Linux에 CRI를 설치하는 사용자를 위해 작성되었다.
|
||||
다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
|
||||
{{< /note >}}
|
||||
|
||||
이 가이드의 모든 명령은 `root`로 실행해야 한다.
|
||||
예를 들어,`sudo`로 접두사를 붙이거나, `root` 사용자가 되어 명령을 실행한다.
|
||||
|
||||
### Cgroup 드라이버
|
||||
|
||||
Linux 배포판의 init 시스템이 systemd인 경우, init 프로세스는
|
||||
root control group(`cgroup`)을 생성 및 사용하는 cgroup 관리자로 작동한다.
|
||||
Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다.
|
||||
컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다.
|
||||
systemd와 함께`cgroupfs`를 사용하면 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다.
|
||||
|
||||
Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다.
|
||||
단일 cgroup 관리자는 할당된 리소스가 무엇인지를 단순화하고,
|
||||
기본적으로 사용가능한 리소스와 사용중인 리소스를 일관성있게 볼 수 있다.
|
||||
관리자가 두 개인 경우, 이런 리소스도 두 개의 관점에서 보게 된다. kubelet과 Docker는
|
||||
`cgroupfs`를 사용하고 나머지 프로세스는
|
||||
`systemd`를 사용하도록 노드가 설정된 경우,
|
||||
리소스가 부족할 때 불안정해지는 사례를 본 적이 있다.
|
||||
|
||||
컨테이너 런타임과 kubelet이 `systemd`를 cgroup 드라이버로 사용하도록 설정을 변경하면
|
||||
시스템이 안정화된다. 아래의 Docker 설정에서 `native.cgroupdriver=systemd` 옵션을 확인하라.
|
||||
|
||||
{{< caution >}}
|
||||
클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 권장하지 않는다.
|
||||
하나의 cgroup 드라이버의 의미를 사용하여 kubelet이 파드를 생성해왔다면,
|
||||
컨테이너 런타임을 다른 cgroup 드라이버로 변경하는 것은 존재하는 기존 파드에 대해 PodSandBox를 재생성을 시도할 때, 에러가 발생할 수 있다.
|
||||
kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다.
|
||||
추천하는 방법은 워크로드에서 노드를 제거하고, 클러스터에서 제거한 다음 다시 결합시키는 것이다.
|
||||
{{< /caution >}}
|
||||
|
||||
## Docker
|
||||
|
||||
각 머신들에 대해서, Docker를 설치한다.
|
||||
버전 18.06.2가 추천된다. 그러나 1.11, 1.12, 1.13, 17.03 그리고 18.09도 동작하는 것으로 알려져 있다.
|
||||
쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 Docker 버전의 지속적인 파악이 필요하다.
|
||||
|
||||
시스템에 Docker를 설치하기 위해서 아래의 커맨드들을 사용한다.
|
||||
|
||||
{{< tabs name="tab-cri-docker-installation" >}}
|
||||
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
|
||||
# Docker CE 설치
|
||||
## 리포지터리 설정
|
||||
### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치
|
||||
apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common
|
||||
|
||||
### Docker의 공식 GPG 키 추가
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
|
||||
|
||||
### Docker apt 리포지터리 추가.
|
||||
add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
|
||||
## Docker CE 설치.
|
||||
apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu
|
||||
|
||||
# 데몬 설정.
|
||||
cat > /etc/docker/daemon.json <<EOF
|
||||
{
|
||||
"exec-opts": ["native.cgroupdriver=systemd"],
|
||||
"log-driver": "json-file",
|
||||
"log-opts": {
|
||||
"max-size": "100m"
|
||||
},
|
||||
"storage-driver": "overlay2"
|
||||
}
|
||||
EOF
|
||||
|
||||
mkdir -p /etc/systemd/system/docker.service.d
|
||||
|
||||
# Docker 재시작.
|
||||
systemctl daemon-reload
|
||||
systemctl restart docker
|
||||
{{< /tab >}}
|
||||
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
|
||||
|
||||
# Docker CE 설치
|
||||
## 리포지터리 설정
|
||||
### 필요한 패키지 설치.
|
||||
yum install yum-utils device-mapper-persistent-data lvm2
|
||||
|
||||
### Docker 리포지터리 추가
|
||||
yum-config-manager \
|
||||
--add-repo \
|
||||
https://download.docker.com/linux/centos/docker-ce.repo
|
||||
|
||||
## Docker CE 설치.
|
||||
yum update && yum install docker-ce-18.06.2.ce
|
||||
|
||||
## /etc/docker 디렉터리 생성.
|
||||
mkdir /etc/docker
|
||||
|
||||
# 데몬 설정.
|
||||
cat > /etc/docker/daemon.json <<EOF
|
||||
{
|
||||
"exec-opts": ["native.cgroupdriver=systemd"],
|
||||
"log-driver": "json-file",
|
||||
"log-opts": {
|
||||
"max-size": "100m"
|
||||
},
|
||||
"storage-driver": "overlay2",
|
||||
"storage-opts": [
|
||||
"overlay2.override_kernel_check=true"
|
||||
]
|
||||
}
|
||||
EOF
|
||||
|
||||
mkdir -p /etc/systemd/system/docker.service.d
|
||||
|
||||
# Docker 재시작.
|
||||
systemctl daemon-reload
|
||||
systemctl restart docker
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
자세한 내용은 [공식 Docker 설치 가이드](https://docs.docker.com/engine/installation/)
|
||||
를 참고한다.
|
||||
|
||||
## CRI-O
|
||||
|
||||
이 섹션은 `CRI-O`를 CRI 런타임으로 설치하는 필수적인 단계를 담고 있다.
|
||||
|
||||
시스템에 CRI-O를 설치하기 위해서 다음의 커맨드를 사용한다.
|
||||
|
||||
### 선행 조건
|
||||
|
||||
```shell
|
||||
modprobe overlay
|
||||
modprobe br_netfilter
|
||||
|
||||
# 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅 간에도 유지된다.
|
||||
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
sysctl --system
|
||||
```
|
||||
|
||||
{{< tabs name="tab-cri-cri-o-installation" >}}
|
||||
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
|
||||
|
||||
# 선행 조건 설치
|
||||
apt-get update
|
||||
apt-get install software-properties-common
|
||||
|
||||
add-apt-repository ppa:projectatomic/ppa
|
||||
apt-get update
|
||||
|
||||
# CRI-O 설치
|
||||
apt-get install cri-o-1.13
|
||||
|
||||
{{< /tab >}}
|
||||
{{< 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/
|
||||
|
||||
# CRI-O 설치
|
||||
yum install --nogpgcheck cri-o
|
||||
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
### CRI-O 시작
|
||||
|
||||
```
|
||||
systemctl start crio
|
||||
```
|
||||
|
||||
자세한 사항은 [CRI-O 설치 가이드](https://github.com/kubernetes-sigs/cri-o#getting-started)
|
||||
를 참고한다.
|
||||
|
||||
## Containerd
|
||||
|
||||
이 섹션은 `containerd`를 CRI 런타임으로써 사용하는데 필요한 단계를 담고 있다.
|
||||
|
||||
Containerd를 시스템에 설치하기 위해서 다음의 커맨드들을 사용한다.
|
||||
|
||||
### 선행 조건
|
||||
|
||||
```shell
|
||||
modprobe overlay
|
||||
modprobe br_netfilter
|
||||
|
||||
# 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅에서도 유지된다.
|
||||
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
sysctl --system
|
||||
```
|
||||
|
||||
### containerd 설치
|
||||
|
||||
{{< tabs name="tab-cri-containerd-installation" >}}
|
||||
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
|
||||
# containerd 설치
|
||||
## 리포지터리 설정
|
||||
### apt가 HTTPS로 리포지터리를 사용하는 것을 허용하기 위한 패키지 설치
|
||||
apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
|
||||
|
||||
### Docker의 공식 GPG 키 추가
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
|
||||
|
||||
### Docker apt 리포지터리 추가.
|
||||
add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
|
||||
## containerd 설치
|
||||
apt-get update && apt-get install -y containerd.io
|
||||
|
||||
# containerd 설정
|
||||
mkdir -p /etc/containerd
|
||||
containerd config default > /etc/containerd/config.toml
|
||||
|
||||
# containerd 재시작
|
||||
systemctl restart containerd
|
||||
{{< /tab >}}
|
||||
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
|
||||
# containerd 설치
|
||||
## 리포지터리 설정
|
||||
### 필요한 패키지 설치
|
||||
yum install yum-utils device-mapper-persistent-data lvm2
|
||||
|
||||
### Docker 리포지터리 추가리
|
||||
yum-config-manager \
|
||||
--add-repo \
|
||||
https://download.docker.com/linux/centos/docker-ce.repo
|
||||
|
||||
## containerd 설치
|
||||
yum update && yum install containerd.io
|
||||
|
||||
# containerd 설정
|
||||
mkdir -p /etc/containerd
|
||||
containerd config default > /etc/containerd/config.toml
|
||||
|
||||
# containerd 재시작
|
||||
systemctl restart containerd
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
### systemd
|
||||
|
||||
`systemd` cgroup driver를 사용하려면, `/etc/containerd/config.toml`의 `plugins.cri.systemd_cgroup = true`을 설정한다.
|
||||
kubeadm을 사용하는 경우에도 마찬가지로, 수동으로
|
||||
[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)을
|
||||
설정해준다.
|
||||
|
||||
## 다른 CRI 런타임: frakti
|
||||
|
||||
자세한 정보는 [Frakti 빠른 시작 가이드](https://github.com/kubernetes/frakti#quickstart)를 참고한다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: 온-프레미스 VM
|
||||
weight: 40
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: Installing Kubernetes with deployment tools
|
||||
weight: 30
|
||||
---
|
||||
@@ -0,0 +1,149 @@
|
||||
---
|
||||
title: Kops로 쿠버네티스 설치하기
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이곳 빠른 시작에서는 사용자가 얼마나 쉽게 AWS에 쿠버네티스 클러스터를 설치할 수 있는지 보여준다.
|
||||
[`kops`](https://github.com/kubernetes/kops)라는 이름의 툴을 이용할 것이다.
|
||||
|
||||
kops는 강력한 프로비저닝 시스템인데,
|
||||
|
||||
* 완전 자동화된 설치
|
||||
* DNS를 통해 클러스터들의 신원 확인
|
||||
* 자체 복구: 모든 자원이 Auto-Scaling Groups에서 실행
|
||||
* 다양한 OS 지원(Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - [images.md](https://github.com/kubernetes/kops/blob/master/docs/images.md) 보기
|
||||
* 고가용성 지원 - [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md) 보기
|
||||
* 직접 프로비저닝 하거나 또는 할 수 있도록 terraform 매니페스트를 생성 - [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md) 보기
|
||||
|
||||
만약 클러스터를 구축하는데 있어 이런 방법이 사용자의 생각과 다르다면 일종의 블록처럼 [kubeadm](/docs/admin/kubeadm/)를 이용할 수도 있다.
|
||||
kops는 kubeadmin 위에서도 잘 동작한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 클러스터 구축
|
||||
|
||||
### (1/5) kops 설치
|
||||
|
||||
#### 요구사항
|
||||
|
||||
kops를 이용하기 위해서는 [kubectl](/docs/tasks/tools/install-kubectl/)이 설치되어 있어야 한다.
|
||||
|
||||
#### 설치
|
||||
|
||||
[releases page](https://github.com/kubernetes/kops/releases)에서 kops를 다운로드 한다(소스코드로부터 빌드하는것도 역시 어렵지 않다).
|
||||
|
||||
MacOS에서:
|
||||
|
||||
```shell
|
||||
curl -OL https://github.com/kubernetes/kops/releases/download/1.10.0/kops-darwin-amd64
|
||||
chmod +x kops-darwin-amd64
|
||||
mv kops-darwin-amd64 /usr/local/bin/kops
|
||||
# Homebrew를 통해 설치할 수도 있다.
|
||||
brew update && brew install kops
|
||||
```
|
||||
|
||||
Linux에서:
|
||||
|
||||
```shell
|
||||
wget https://github.com/kubernetes/kops/releases/download/1.10.0/kops-linux-amd64
|
||||
chmod +x kops-linux-amd64
|
||||
mv kops-linux-amd64 /usr/local/bin/kops
|
||||
```
|
||||
|
||||
### (2/5) 클러스터에 사용할 route53 domain 생성
|
||||
kops는 디스커버리를 위해 클러스터 내외부에서 DNS를 이용하고 이를 통해 사용자는 쿠버네티스 API서버에 도달할 수 있다.
|
||||
|
||||
이런 클러스터 이름에 kops는 명확한 견해을 가지는데: 반드시 유효한 DNS 이름이어야 한다. 이렇게 함으로써
|
||||
사용자는 클러스터를 헷갈리지 않을것이고, 동료들과 혼선없이 공유할 수 있으며, IP를 기억할 필요없이 접근할 수 있다.
|
||||
|
||||
그렇게 하고 있겠지만, 클러스터를 구분하기 위해 서브도메인을 활용할 수 있다. 예를 들어 `useast1.dev.example.com`을 이용한다면, API 서버 엔드포인트는 `api.useast1.dev.example.com`가 될 것이다.
|
||||
|
||||
Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone은 `useast1.dev.example.com`, `dev.example.com` 그리고 `example.com` 같은 것도 될 수 있다.
|
||||
kops는 이것들 모두와 잘 동작하며, 사용자는 보통 조직적인 부분을 고려해 결정한다(예를 들어, 사용자가 `dev.example.com`하위에 레코드를 생성하는것은 허용되지만,
|
||||
`example.com`하위에는 그렇지 않을 수 있다).
|
||||
|
||||
`dev.example.com`을 hosted zone으로 사용하고 있다고 가정해보자.
|
||||
보통 사용자는 [일반적인 방법](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나
|
||||
`aws route53 create-hosted-zone --name dev.example.com --caller-reference 1` 와 같은 커맨드를 이용한다.
|
||||
그 후 도메인 내 레코드들을 확인할 수 있도록 상위 도메인내에 NS 레코드를 생성해야 한다. 여기서는, `dev` NS 레코드를 `example.com`에 생성한다. 만약 이것이 루트 도메인 네임이라면 이 NS 레코드들은 도메인 등록기관을 통해서 생성해야 한다(예를 들어, `example.com`는 `example.com`를 구매한 곳에서 설정 할 수 있다).
|
||||
|
||||
이 단계에서 문제가 되기 쉽다.(문제를 만드는 가장 큰 이유이다!) dig 툴을 실행해서 클러스터 설정이 정확한지 한번 더 확인 한다.
|
||||
|
||||
`dig NS dev.example.com`
|
||||
|
||||
당신의 hosted zone용으로 할당된 3~4개의 NS 레코드를 Route53에서 확인할 수 있어야 한다.
|
||||
|
||||
### (3/5) 클러스터 상태 저장용 S3 버킷 생성
|
||||
kops는 설치 이후에도 클러스터를 관리할 수 있다. 이를 위해 사용자가 생성한 클러스터의 상태나 사용하는 키 정보들을 지속적으로 추적해야 한다. 이 정보가 S3에 저장된다.
|
||||
이 버킷의 접근은 S3 권한으로 제어한다.
|
||||
|
||||
다수의 클러스터는 동일한 S3 버킷을 이용할 수 있고, 사용자는 이 S3 버킷을 같은 클러스트를 운영하는 동료에게 공유할 수 있다. 하지만 이 S3 버킷에 접근 가능한 사람은 사용자의 모든 클러스터에 관리자 접근이 가능하게 되니, 운영팀 이외로 공유되지 않도록 해야 한다.
|
||||
|
||||
그래서 보통 한 운영팀 당 하나의 S3 버킷을 가지도록 하기도 한다.(그리고 종종 운영팀 이름은 위에서 언급한 hosted zone과 동일하게 짓기도 한다!)
|
||||
|
||||
우리 예제에서는, `dev.example.com`를 hosted zone으로 했으니 `clusters.dev.example.com`를 S3 버킷 이름으로 정하자.
|
||||
|
||||
* `AWS_PROFILE`를 선언한다. (AWS CLI 동작을 위해 다른 profile을 선택해야 할 경우)
|
||||
|
||||
* `aws s3 mb s3://clusters.dev.example.com`를 이용해 S3 버킷을 생성한다.
|
||||
|
||||
* `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 하면, kops는 이 위치를 기본값으로 인식할 것이다.
|
||||
이 부분을 bash profile등에 넣어두는것을 권장한다.
|
||||
|
||||
### (4/5) 클러스터 설정 구성
|
||||
클러스터 설정하려면, `kops create cluster` 를 실행한다:
|
||||
|
||||
`kops create cluster --zones=us-east-1c useast1.dev.example.com`
|
||||
|
||||
kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의할 점은 실제 클러스트 리소스가 아닌 _설정_ 만을 생성한다는 것에 주의하자 - 이 부분은 다음 단계에서 `kops update cluster` 으로 구성해볼 것이다. 그 때 만들어진 설정을 점검하거나 변경할 수 있다.
|
||||
|
||||
더 자세한 내용을 알아보기 위한 커맨드가 출력된다.
|
||||
|
||||
* 클러스터 조회: `kops get cluster`
|
||||
* 클러스트 수정: `kops edit cluster useast1.dev.example.com`
|
||||
* 인스턴스 그룹 수정: `kops edit ig --name=useast1.dev.example.com nodes`
|
||||
* 마스터 인스턴스 그룹 수정: `kops edit ig --name=useast1.dev.example.com master-us-east-1c`
|
||||
|
||||
만약 kops사용이 처음이라면, 얼마 걸리지 않으니 이들을 시험해 본다. 인스턴스 그룹은 쿠버네티스 노드로 등록된 인스턴스의 집합을 말한다. AWS상에서는 auto-scaling-groups를 통해 만들어진다. 사용자는 여러개의 인스턴스 그룹을 관리할 수 있는데, 예를 들어, spot과 on-demand 인스턴스 조합 또는 GPU 와 non-GPU 인스턴스의 조합으로 구성할 수 있다.
|
||||
|
||||
|
||||
### (5/5) AWS에 클러스터 생성
|
||||
|
||||
`kops update cluster`를 실행해 AWS에 클러스터를 생성한다.
|
||||
|
||||
`kops update cluster useast1.dev.example.com --yes`
|
||||
|
||||
실행은 수 초 만에 되지만, 실제로 클러스터가 준비되기 전까지 수 분이 걸릴 수 있다.
|
||||
언제든 `kops update cluster`로 클러스트 설정을 변경할 수 있다. 사용자가 변경한 클러스트 설정을 그대로 반영해 줄 것이며, 필요다하면 AWS 나 쿠버네티스를 재설정 해 줄것이다.
|
||||
|
||||
예를 들면, `kops edit ig nodes` 뒤에 `kops update cluster --yes`를 실행해 설정을 반영한다. 그리고 `kops rolling-update cluster`로 설정을 즉시 원복시킬 수 있다.
|
||||
|
||||
`--yes`를 명시하지 않으면 `kops update cluster` 커맨드 후 어떤 설정이 변경될지가 표시된다. 운영계 클러스터 관리할 때 사용하기 좋다!
|
||||
|
||||
|
||||
### 다른 애드온 탐험
|
||||
[애드온 리스트](/docs/concepts/cluster-administration/addons/) 에서 쿠버네티스 클러스터용 로깅, 모니터링, 네트워크 정책, 시각화 & 제어 등을 포함한 다른 애드온을 확인해본다.
|
||||
|
||||
## 정리하기
|
||||
|
||||
* `kops delete cluster useast1.dev.example.com --yes` 로 클러스터를 삭제한다.
|
||||
|
||||
## Feedback
|
||||
|
||||
* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
|
||||
* [GitHub Issues](https://github.com/kubernetes/kops/issues)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* 쿠버네티스 [개념](/docs/concepts/) 과 [`kubectl`](/docs/user-guide/kubectl-overview/)에 대해 더 알아보기.
|
||||
* `kops` [고급 사용법](https://github.com/kubernetes/kops) 알아보기.
|
||||
* 튜토리얼, 모범사례, 고급 설정 옵션을 위해 `kops` [문서](https://github.com/kubernetes/kops) 부분 보기.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: 턴키 클라우드 솔루션
|
||||
weight: 30
|
||||
---
|
||||
Reference in New Issue
Block a user