kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

[ko] Remove files deleted from upstream

pull/35525/head
Jihoon Seo 2022-07-29 12:11:42 +09:00
parent 75ee9935bd
commit 6efed264cb
5 changed files with 0 additions and 593 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

232
content/ko/docs/concepts/extend-kubernetes/service-catalog.md
View File

@ -1,232 +0,0 @@
---
title: 서비스 카탈로그
content_type: concept
weight: 40
---
<!-- overview -->
{{< glossary_definition term_id="service-catalog" length="all" prepend="서비스 카탈로그는" >}}
[오픈 서비스 브로커 API 명세](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)에 정의된 서비스 브로커는 AWS, GCP 또는 Azure와 같은 타사 클라우드 공급자에 의해 제공되고 관리되는 매니지드 서비스의 세트에 대한 엔드포인트다.
매니지드 서비스의 예로 Microsoft Azure Cloud Queue, Amazon Simple Quere Service, Google Cloud Pub/Sub이 있으나 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품일 수 있다.
{{< glossary_tooltip text="클러스터 오퍼레이터" term_id="cluster-operator" >}}는 서비스 카탈로그를 사용하여 서비스 브로커가 제공하는 매니지드 서비스 목록을 탐색하거나 매니지드 서비스 인스턴스를 프로비저닝하고, 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있도록 바인딩할 수 있다.
<!-- body -->
## 유스케이스 예제
한 {{< glossary_tooltip text="애플리케이션 개발자" term_id="application-developer" >}}가 쿠버네티스 클러스터 내에서 실행되는 애플리케이션 중 일부로 메시지 큐를 사용하기를 원한다.
그러나 그러한 서비스에 대한 설정과 관리에는 부담이 따른다.
다행히 서비스 브로커를 통해 메시지 큐를 매니지드 서비스로 제공하는 클라우드 공급자가 있다.
클러스터 운영자는 서비스 카탈로그를 설정하고 이를 이용하여 클라우드 공급자의 서비스 브로커와 통신하여 메시지 큐 서비스의 인스턴스를 프로비저닝하고 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있게 한다.
따라서 애플리케이션 개발자는 메시지 큐의 세부 구현 또는 관리에 신경 쓸 필요가 없다.
애플리케이션은 메시지 큐에 서비스로 접속할 수 있다.
## 아키텍처
서비스 카탈로그는 [오픈 서비스 브로커 API](https://github.com/openservicebrokerapi/servicebroker)를 사용하여 쿠버네티스 API 서버가 초기 프로비저닝을 협상하고 애플리케이션이 매니지드 서비스를 사용하는데 필요한 자격 증명을 검색하는 중개자 역할을 하는 서비스 브로커와 통신한다.
이는 [CRD 기반](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/#커스텀-리소스) 아키텍처를 사용해서 구현되었다.
<br>
![Service Catalog Architecture](/images/docs/service-catalog-architecture.svg)
### API 리소스
서비스 카탈로그는 `servicecatalog.k8s.io` API를 설치하고 다음 쿠버네티스 리소스를 제공한다.
* `ClusterServiceBroker`: 서버 연결 세부 사항을 캡슐화한, 서비스 브로커의 클러스터 내부 대표.
이들은 클러스터 내에서 새로운 유형의 매니지드 서비스를 사용할 수 있도록 하려는 클러스터 운영자가 만들고 관리한다.
* `ClusterServiceClass`: 특정 서비스 브로커가 제공하는 매니지드 서비스.
새로운 `ClusterServiceBroker` 리소스가 클러스터에 추가되면 서비스 카탈로그 컨트롤러는 서비스 브로커에 연결해서 사용 가능한 매니지드 서비스 목록을 얻는다. 그 다음 각 매니지드 서비스에 해당하는 새로운 `ClusterServiceClass` 리소스를 만든다.
* `ClusterServicePlan`: 매니지드 서비스의 특별 요청. 예를 들어, 매니지드 서비스는 무료 혹은 유료 티어와 같이 사용 가능한 서로 다른 상품이 있거나, SSD 스토리지를 사용하거나 더 많은 리소스를 갖는 등 다른 구성 옵션을 가질 수 있다. `ClusterServiceClass`와 유사하게, 새로운 `ClusterServiceBroker`가 클러스터에 추가되면, 서비스 카탈로그는 각 매니지드 서비스에 사용 가능한 서비스 플랜에 해당하는 새로운 `ClusterServicePlan` 리소스를 작성한다.
* `ServiceInstance`: `ClusterServiceClass`의 프로비저닝된 인스턴스.
클러스터 운영자가 하나 이상의 클러스터 애플리케이션에서 사용할 수 있도록 매니지드 서비스의 특정 인스턴스를 사용하기 위해 생성한다.
새로운 `ServiceInstance`리소스가 생성되면, 서비스 카탈로그 컨트롤러는 해당 서비스 브로커에 연결하여 서비스 인스턴스를 프로비저닝하도록 지시한다.
* `ServiceBinding`: `ServiceInstance`에 대한 자격 증명에 액세스한다.
자신의 애플리케이션이 `ServiceInstance`를 사용하기를 원하는 클러스터 운영자가 이들을 생성한다.
서비스 카탈로그 컨트롤러는 생성 시 파드에 마운트될 수 있는 서비스 인스턴스에 대한 연결 세부 정보와 자격 증명이 포함된 쿠버네티스 '시크릿(secret)'을 생성한다.
### 인증
서비스 카탈로그는 다음의 인증 방법을 지원한다.
* 기본 (username/password)
* [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750)
## 사용법
클러스터 운영자는 서비스 카탈로그 API 리소스를 사용하여 매니지드 서비스를 프로비저닝하여 쿠버네티스 클러스터 내에서 사용할 수 있게 한다. 관련 단계는 다음과 같다.
1. 서비스 브로커에서 사용 가능한 매니지드 서비스와 서비스 플랜을 나열.
1. 매니지드 서비스의 새 인스턴스 프로비저닝.
1. 연결 자격 증명을 반환하는 매니지드 서비스에 바인딩.
1. 연결 자격 증명을 애플리케이션에 매핑.
### 매니지드 서비스와 서비스 플랜 나열
먼저, 클러스터 운영자는 `servicecatalog.k8s.io` 그룹 내에 `ClusterServiceBroker` 리소스를 생성해야 한다. 이 리소스는 서비스 브로커 엔드포인트에 접근하는데 필요한 URL과 연결 세부 사항을 포함한다.
다음은 `ClusterServiceBroker` 리소스 예시이다.
```yaml
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ClusterServiceBroker
metadata:
name: cloud-broker
spec:
# 서비스 브로커의 엔드포인트를 가리킨다. (이 예시는 동작하지 않는 URL이다.)
url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default
#####
# bearer 토큰 정보 혹은 TLS용 caBundle과 같은
# 서비스 브로커와 통신하는데 사용될 수 있는 값을 여기에 추가할 수 있다.
#####
```
다음은 서비스 브로커에서 사용 가능한 매니지드 서비스와 플랜을 나열하는 단계를 설명하는 시퀀스 다이어그램이다.
![List Services](/images/docs/service-catalog-list.svg)
1. `ClusterServiceBroker` 리소스가 서비스 카탈로그에 추가되면, 사용 가능한 서비스 목록에 대한 외부 서비스 브로커에 대한 호출을 발생시킨다.
1. 서비스 브로커는 사용 가능한 매니지드 서비스 목록과 서비스 플랜 목록을 반환한다. 이 목록은 각각 로컬 `ClusterServiceClass`와 `ClusterServicePlan` 리소스로 캐시된다.
1. 그런 다음 클러스터 운영자는 다음의 명령어를 사용하여 가용한 관리 서비스 목록을 얻을 수 있다.
kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
아래와 같은 형태의 서비스 이름 목록이 출력된다.
SERVICE NAME EXTERNAL NAME
4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service
... ...
또한 다음의 명령어를 사용하여 가용한 서비스 플랜을 볼 수 있다.
kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
아래와 같은 형태의 플랜 이름 목록이 출력된다.
PLAN NAME EXTERNAL NAME
86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name
... ...
### 새 인스턴스 프로비저닝
클러스터 운영자는 `ServiceInstance` 리소스를 생성하여 새 인스턴스 프로비저닝을 시작할 수 있다.
다음은 `ServiceInstance` 리소스의 예시이다.
```yaml
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
name: cloud-queue-instance
namespace: cloud-apps
spec:
# 이전에 반환된 서비스 중 하나를 참조
clusterServiceClassExternalName: cloud-provider-service
clusterServicePlanExternalName: service-plan-name
#####
# 이곳에 서비스 브로커가 사용할 수 있는
# 파라미터를 추가할 수 있다.
#####
```
다음의 시퀀스 다이어그램은 매니지드 서비스의 새 인스턴스 프로비저닝과 관련된 일련의 단계를 보여준다.
![Provision a Service](/images/docs/service-catalog-provision.svg)
1. `ServiceInstance` 리소스가 생성되면, 서비스 카탈로그는 서비스 인스턴스를 프로비저닝하기 위해 외부의 서비스 브로커 호출을 초기화한다.
1. 서비스 브로커는 새로운 매니지드 서비스 인스턴스를 생성하고 HTTP 응답을 리턴한다.
1. 그 후 클러스터 운영자는 인스턴스 상태가 준비되었는지 점검할 수 있다.
### 매니지드 서비스에 바인딩
새 인스턴스가 프로비저닝된 후, 클러스터 운영자는 애플리케이션이 서비스를 사용하는데 필요한 자격 증명을 얻기 위해 매니지드 서비스에 바인드해야 한다. 이것은 `ServiceBinding` 리소스를 생성하는 것으로 이루어진다.
다음은 `ServiceBinding` 리소스의 예시다.
```yaml
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
name: cloud-queue-binding
namespace: cloud-apps
spec:
instanceRef:
name: cloud-queue-instance
#####
# 서비스 브로커가 사용할 수 있는 secretName, 서비스 어카운트 파라미터 등의
# 추가 정보를 여기에 추가할 수 있다.
#####
```
다음의 시퀀스 다이어그램은 매니지드 서비스 인스턴스에 바인딩하는 단계를 보여준다.
![Bind to a managed service](/images/docs/service-catalog-bind.svg)
1. `ServiceBinding`이 생성된 이후, 서비스 카탈로그는 서비스 인스턴스와 바인딩하는데 필요한 정보를 요청하는 외부 서비스 브로커를 호출한다.
1. 서비스 브로커는 적절한 서비스 어카운트에 대한 애플리케이션 권한/역할을 활성화한다.
1. 서비스 브로커는 매니지드 서비스 인스턴스에 연결하고 액세스하는데 필요한 정보를 리턴한다. 이는 제공자와 서비스에 특화되어 있으므로 서비스 프로바이더와 매니지드 서비스에 따라 다를 수 있다.
### 연결 자격 증명 매핑
바인딩 후 마지막 단계는 연결 자격 증명과 서비스 특화 정보를 애플리케이션에 매핑하는 것이다.
이런 정보는 클러스터의 애플리케이션이 액세스하여 매니지드 서비스와 직접 연결하는데 사용할 수 있는 시크릿으로 저장된다.
<br>
![Map connection credentials](/images/docs/service-catalog-map.svg)
#### 파드 구성 파일
이 매핑을 수행하는 한 가지 방법은 선언적 파드 구성을 사용하는 것이다.
다음 예시는 서비스 자격 증명을 애플리케이션에 매핑하는 방법을 설명한다. `sa-key`라는 키는 `provider-cloud-key`라는 볼륨에 저장되며, 애플리케이션은 이 볼륨을 `/var/secrets/provider/key.json`에 마운트한다. 환경 변수 `PROVIDER_APPLICATION_CREDENTIALS`는 마운트된 파일의 값에서 매핑된다.
```yaml
...
spec:
volumes:
- name: provider-cloud-key
secret:
secretName: sa-key
containers:
...
volumeMounts:
- name: provider-cloud-key
mountPath: /var/secrets/provider
env:
- name: PROVIDER_APPLICATION_CREDENTIALS
value: "/var/secrets/provider/key.json"
```
다음 예시는 시크릿 값을 애플리케이션 환경 변수에 매핑하는 방법을 설명한다. 이 예시에서 메시지 큐 토픽 이름은 `topic` 라는 키의 `provider-queue-credentials` 시크릿에서 환경 변수 `TOPIC`에 매핑된다.
```yaml
...
env:
- name: "TOPIC"
valueFrom:
secretKeyRef:
name: provider-queue-credentials
key: topic
```
## {{% heading "whatsnext" %}}
* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/ko/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다.
* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색

22
content/ko/docs/reference/glossary/service-broker.md
View File

@ -1,22 +0,0 @@
---
title: 서비스 브로커(Service Broker)
id: service-broker
date: 2018-04-12
full_link:
short_description: >
서드파티에서 제공하고 유지 관리하는 일련의 매니지드 서비스에 대한 엔드포인트이다.
aka:
tags:
- extension
---
서드파티에서 제공하고 유지 관리하는 일련의 {{< glossary_tooltip text="매니지드 서비스" term_id="managed-service" >}}에 대한 엔드포인트이다.
<!--more-->
{{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}는
[오픈 서비스 브로커 API 명세](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)를
구현하고 애플리케이션이 매니지드 서비스를 사용할 수 있도록 표준 인터페이스를 제공한다.
[서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)는
서비스 브로커가 제공하는 매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다.

256
content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
View File

@ -1,256 +0,0 @@
---
title: 윈도우 노드 추가
min-kubernetes-server-version: 1.17
content_type: tutorial
weight: 30
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
쿠버네티스를 사용하여 리눅스와 윈도우 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 윈도우에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 윈도우 노드를 클러스터에 등록하는 방법을 보여준다.
## {{% heading "prerequisites" %}}
{{< version-check >}}
* 윈도우 컨테이너를 호스팅하는 윈도우 노드를 구성하려면
[윈도우 서버 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) 이상이 필요하다.
VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://support.microsoft.com/help/4489899)도 설치되어 있어야 한다.
* 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 kubeadm 클러스터([kubeadm을 사용하여 단일 컨트롤 플레인 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 참고)가 필요하다.
## {{% heading "objectives" %}}
* 클러스터에 윈도우 노드 등록
* 리눅스 및 윈도우의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성
<!-- lessoncontent -->
## 시작하기: 클러스터에 윈도우 노드 추가
### 네트워킹 구성
리눅스 기반 쿠버네티스 컨트롤 플레인 노드가 있으면 네트워킹 솔루션을 선택할 수 있다. 이 가이드는 VXLAN 모드의 플란넬(Flannel)을 사용하는 방법을 짧막하게 보여준다.
#### 플란넬 구성
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
```
VNI를 4096으로 설정하고 포트를 4789로 설정하려면 플란넬 매니페스트의 `net-conf.json` 섹션을 수정한다. 다음과 같을 것이다.
```json
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan",
"VNI": 4096,
"Port": 4789
}
}
```
{{< note >}}리눅스의 플란넬이 윈도우의 플란넬과 상호 운용되도록 하려면 VNI를 4096으로, 포트를 4789로 설정해야 한다. 이 필드들에 대한 설명은 [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)를
참고한다.{{< /note >}}
{{< note >}}L2Bridge/Host-gateway 모드를 대신 사용하려면 `Type` 의 값을 `"host-gw"` 로 변경하고 `VNI` 와 `Port` 를 생략한다.{{< /note >}}
1. 플란넬 매니페스트 적용 및 유효성 검사
플란넬 구성을 적용해보자.
```bash
kubectl apply -f kube-flannel.yml
```
몇 분 후에, 플란넬 파드 네트워크가 배포되었다면 모든 파드가 실행 중인 것으로 표시된다.
```bash
kubectl get pods -n kube-system
```
출력 결과에 리눅스 flannel 데몬셋(DaemonSet)이 실행 중인 것으로 나와야 한다.
```
NAMESPACE NAME READY STATUS RESTARTS AGE
...
kube-system kube-flannel-ds-54954 1/1 Running 0 1m
```
1. 윈도우 플란넬 및 kube-proxy 데몬셋 추가
이제 윈도우 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한
kube-proxy 버전을 얻으려면, 이미지의 태그를
대체해야 한다. 다음의 예시는 쿠버네티스 {{< param "fullversion" >}}의 사용법을 보여주지만,
사용자의 배포에 맞게 버전을 조정해야 한다.
```bash
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml
```
{{< note >}}
host-gateway를 사용하는 경우 https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml 을 대신 사용한다.
{{< /note >}}
{{< note >}}
윈도우 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다.
```powershell
wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
```
그리고, 이에 따라 인터페이스를 지정해야 한다.
```bash
# 예시
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f -
```
{{< /note >}}
### 윈도우 워커 노드 조인(joining)
{{< note >}}
윈도우 섹션의 모든 코드 스니펫(snippet)은 윈도우 워커 노드의
높은 권한(관리자)이 있는 PowerShell 환경에서 실행해야 한다.
{{< /note >}}
{{< tabs name="tab-windows-kubeadm-runtime-installation" >}}
{{% tab name="CRI-containerD" %}}
#### containerD 설치
```powershell
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/Install-Containerd.ps1
.\Install-Containerd.ps1
```
{{< note >}}
특정 버전의 containerD를 설치하려면 -ContainerDVersion를 사용하여 버전을 지정한다.
```powershell
# 예
.\Install-Containerd.ps1 -ContainerDVersion 1.4.1
```
윈도우 노드에서 이더넷(예: "Ethernet0 2")이 아닌 다른 인터페이스를 사용하는 경우, `-netAdapterName` 으로 이름을 지정한다.
```powershell
# 예
.\Install-Containerd.ps1 -netAdapterName "Ethernet0 2"
```
{{< /note >}}
#### wins, kubelet 및 kubeadm 설치
```PowerShell
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
```
kubeadm이 CRI 엔드포인트와 통신하기 위해 필요한
[`crictl`을 cri-tools 패키지로부터 설치한다](https://github.com/kubernetes-sigs/cri-tools).
#### `kubeadm` 실행하여 노드에 조인
컨트롤 플레인 호스트에서 `kubeadm init` 실행할 때 제공된 명령을 사용한다.
이 명령이 더 이상 없거나, 토큰이 만료된 경우, `kubeadm token create --print-join-command`
(컨트롤 플레인 호스트에서)를 실행하여 새 토큰 및 조인 명령을 생성할 수 있다.
{{% /tab %}}
{{% tab name="Docker Engine" %}}
#### Docker Engine 설치
`컨테이너` 기능 설치
```powershell
Install-WindowsFeature -Name containers
```
도커 설치에 대한
자세한 내용은 [도커 엔진 설치 - 윈도우 서버 엔터프라이즈](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker)에서 확인할 수 있다.
kubelet이 CRI 호환 엔드포인트를 통해 도커와 통신하기 위해 필요한
[cri-dockerd를 설치](https://github.com/Mirantis/cri-dockerd)한다.
{{< note >}}
도커 엔진은 컨테이너 런타임이 쿠버네티스와 호환되기 위한 요구 사항인
[CRI](/ko/docs/concepts/architecture/cri/)를 만족하지 않는다.
이러한 이유로, 추가 서비스인 [cri-dockerd](https://github.com/Mirantis/cri-dockerd)가 설치되어야 한다.
cri-dockerd는 쿠버네티스 버전 1.24부터 kubelet에서 [제거](/dockershim/)된
기존 내장 도커 엔진 지원을 기반으로 한 프로젝트이다.
{{< /note >}}
kubeadm이 CRI 엔드포인트와 통신하기 위해 필요한
`crictl`을 [cri-tools 프로젝트](https://github.com/kubernetes-sigs/cri-tools)로부터 설치한다.
#### wins, kubelet 및 kubeadm 설치
```PowerShell
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
```
#### `kubeadm` 실행하여 노드에 조인
컨트롤 플레인 호스트에서 `kubeadm init` 실행할 때 제공된 명령을 사용한다.
이 명령이 더 이상 없거나, 토큰이 만료된 경우, `kubeadm token create --print-join-command`
(컨트롤 플레인 호스트에서)를 실행하여 새 토큰 및 조인 명령을 생성할 수 있다.
{{% /tab %}}
{{< /tabs >}}
### 설치 확인
이제 다음을 실행하여 클러스터에서 윈도우 노드를 볼 수 있다.
```bash
kubectl get nodes -o wide
```
새 노드가 `NotReady` 상태인 경우 플란넬 이미지가 여전히 다운로드 중일 수 있다.
`kube-system` 네임스페이스에서 flannel 파드를 확인하여 이전과 같이 진행 상황을 확인할 수 있다.
```shell
kubectl -n kube-system get pods -l app=flannel
```
flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드를 처리할 수 있어야 한다.
## {{% heading "whatsnext" %}}
- [윈도우 kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)

5
content/ko/docs/tasks/service-catalog/_index.md
View File

@ -1,5 +0,0 @@
---
title: "서비스 카탈로그"
description: 서비스 카탈로그 익스텐션(extension) API를 설치한다.
weight: 150
---

78
content/ko/docs/tasks/service-catalog/install-service-catalog-using-sc.md
View File

@ -1,78 +0,0 @@
---
title: SC로 서비스 카탈로그 설치하기
content_type: task
---
<!-- overview -->
{{< glossary_definition term_id="service-catalog" length="all" prepend="서비스 카탈로그는" >}}
GCP [서비스 카탈로그 설치 프로그램](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)
도구로 쿠버네티스 클러스터에 서비스 카탈로그를 쉽게 설치하거나 제거하여
Google Cloud 프로젝트에 연결할 수 있다.
서비스 카탈로그는 Google Cloud뿐 아니라 모든 종류의 관리형 서비스와 함께 작동할 수 있다.
## {{% heading "prerequisites" %}}
* [서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)의 핵심 개념을 이해한다.
* [Go 1.6+](https://golang.org/dl/)를 설치하고 `GOPATH`를 설정한다.
* SSL 아티팩트 생성에 필요한 [cfssl](https://github.com/cloudflare/cfssl) 도구를 설치한다.
* 서비스 카탈로그에는 Kubernetes 버전 1.7 이상이 필요하다.
* [kubectl 설치 및 설정](/ko/docs/tasks/tools/)을 사용하여 Kubernetes 버전 1.7 이상의 클러스터에 연결하도록 구성한다.
* kubectl 사용자는 서비스 카탈로그를 설치하기 위해 *cluster-admin* 역할에 바인딩되어야 한다. 이것이 사실인지 확인하려면 다음 명령을 실행한다.
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
<!-- steps -->
## 로컬 환경에 `sc` 설치하기
설치 프로그램은 로컬 컴퓨터에서 `sc`라는 CLI 도구로 실행된다.
`go get`을 사용하여 설치한다.
```shell
go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc
```
`sc`는 이제 `GOPATH/bin` 디렉토리에 설치되어야 한다.
## 쿠버네티스 클러스터에 서비스 카탈로그 설치하기
먼저 명령을 실행하여 모든 종속성이 설치되었는지 확인한다.
```shell
sc check
```
확인에 성공하면 다음을 반환해야 한다.
```
Dependency check passed. You are good to go.
```
그런 다음 설치 명령을 실행하고 백업에 사용할 `storageclass`를 지정한다.
```shell
sc install --etcd-backup-storageclass "standard"
```
## 서비스 카탈로그 제거하기
`sc` 도구를 사용하여 쿠버네티스 클러스터에서 서비스 카탈로그를 제거하려면 다음을 실행한다.
```shell
sc uninstall
```
## {{% heading "whatsnext" %}}
* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색