Seventh Korean l10n work for release 1.18
- Translate reference/command-line-tools-reference/feature-gates.md int… (#22240) - Fix issue of broken links to translated docs (#22105) - Fix issue of document link in some ko documents (#22379) - Translate tasks/administer-cluster/access-cluster-services.md into Ko… (#21776) - Fix issue with 'Linux' and 'Windows' notation in Korean docs (#22362) - Fix issue of broken links to translated docs #2 (#22270) - Fix issue with k8s.io/ko/docs/concepts/overview/kubernetes-api.md (#22261) - Fix issue with k8s.io/ko/docs/concepts/overview/working-with-objects/ (#22263) - Fix incorrect notation of 'directory' into Korean (#22155) - Fix issue with k8s.io/ko/docs/concepts/overview/components.md (#22232) - Update outdated files in dev-1.18-ko.7 (#22128) - Modify spacing term ReplicaSet in Korean (#22148) - Translate tasks/administer-cluster/extended-resource-node.md into Korean (#21849) - Translate tasks/administer-cluster/access-cluster-api.md into Korean (#21730) Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: woopyoung <ywp041@gmail.com> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: PyungHo Yoon <learder@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: Ian Y. Choi <ianyrchoi@gmail.com>
This commit is contained in:
June Yi
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: "클러스터 운영"
|
||||
description: 클러스터를 운영하기 위한 공통 태스크를 배운다.
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,451 @@
|
||||
---
|
||||
title: 쿠버네티스 API를 사용하여 클러스터에 접근하기
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
이 페이지는 쿠버네티스 API를 사용하여 클러스터에 접근하는 방법을 보여준다.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 쿠버네티스 API에 접근
|
||||
|
||||
### kubectl을 사용하여 처음으로 접근
|
||||
|
||||
쿠버네티스 API에 처음 접근하는 경우, 쿠버네티스
|
||||
커맨드 라인 도구인 `kubectl` 을 사용한다.
|
||||
|
||||
클러스터에 접근하려면, 클러스터 위치를 알고 접근할 수 있는 자격 증명이
|
||||
있어야 한다. 일반적으로, [시작하기 가이드](/ko/docs/setup/)를
|
||||
통해 작업하거나,
|
||||
다른 사람이 클러스터를 설정하고 자격 증명과 위치를 제공할 때 자동으로 설정된다.
|
||||
|
||||
다음의 명령으로 kubectl이 알고 있는 위치와 자격 증명을 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
많은 [예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)는 kubectl 사용에 대한 소개를
|
||||
제공한다. 전체 문서는 [kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에 있다.
|
||||
|
||||
### REST API에 직접 접근
|
||||
|
||||
kubectl은 API 서버 찾기와 인증을 처리한다. `curl` 이나 `wget` 과 같은 http 클라이언트 또는 브라우저를 사용하여 REST API에
|
||||
직접 접근하려는 경우, API 서버를 찾고 인증할 수 있는 여러 가지 방법이 있다.
|
||||
|
||||
1. 프록시 모드에서 kubectl을 실행한다(권장). 이 방법은 저장된 API 서버 위치를 사용하고 자체 서명된 인증서를 사용하여 API 서버의 ID를 확인하므로 권장한다. 이 방법을 사용하면 중간자(man-in-the-middle, MITM) 공격이 불가능하다.
|
||||
1. 또는, 위치와 자격 증명을 http 클라이언트에 직접 제공할 수 있다. 이 방법은 프록시를 혼란스럽게 하는 클라이언트 코드와 동작한다. 중간자 공격으로부터 보호하려면, 브라우저로 루트 인증서를 가져와야 한다.
|
||||
|
||||
Go 또는 Python 클라이언트 라이브러리를 사용하면 프록시 모드에서 kubectl에 접근할 수 있다.
|
||||
|
||||
#### kubectl 프록시 사용
|
||||
|
||||
다음 명령은 kubectl을 리버스 프록시로 작동하는 모드에서 실행한다. API
|
||||
서버 찾기와 인증을 처리한다.
|
||||
|
||||
다음과 같이 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080 &
|
||||
```
|
||||
|
||||
자세한 내용은 [kubectl 프록시](/docs/reference/generated/kubectl/kubectl-commands/#proxy)를 참고한다.
|
||||
|
||||
그런 다음 curl, wget 또는 브라우저를 사용하여 API를 탐색할 수 있다.
|
||||
|
||||
```shell
|
||||
curl http://localhost:8080/api/
|
||||
```
|
||||
|
||||
출력은 다음과 비슷하다.
|
||||
|
||||
```json
|
||||
{
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
#### kubectl 프록시 없이 접근
|
||||
|
||||
다음과 같이 인증 토큰을 API 서버에 직접 전달하여 kubectl 프록시
|
||||
사용을 피할 수 있다.
|
||||
|
||||
`grep/cut` 방식을 사용한다.
|
||||
|
||||
```shell
|
||||
# .KUBECONFIG에 여러 콘텍스트가 있을 수 있으므로, 가능한 모든 클러스터를 확인한다.
|
||||
kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'
|
||||
|
||||
# 위의 출력에서 상호 작용하려는 클러스터의 이름을 선택한다.
|
||||
export CLUSTER_NAME="some_server_name"
|
||||
|
||||
# 클러스터 이름을 참조하는 API 서버를 가리킨다.
|
||||
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
|
||||
|
||||
# 토큰 값을 얻는다
|
||||
TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode)
|
||||
|
||||
# TOKEN으로 API 탐색
|
||||
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
```
|
||||
|
||||
출력은 다음과 비슷하다.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
`jsonpath` 방식을 사용한다.
|
||||
|
||||
```shell
|
||||
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
|
||||
TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
|
||||
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
위의 예는 `--insecure` 플래그를 사용한다. 이로 인해 MITM 공격이
|
||||
발생할 수 있다. kubectl이 클러스터에 접근하면 저장된 루트 인증서와
|
||||
클라이언트 인증서를 사용하여 서버에 접근한다. (`~/.kube` 디렉터리에
|
||||
설치된다.) 클러스터 인증서는 일반적으로 자체 서명되므로,
|
||||
http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한 구성이
|
||||
필요할 수 있다.
|
||||
|
||||
일부 클러스터에서, API 서버는 인증이 필요하지 않다.
|
||||
로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은
|
||||
없다. [API에 대한 접근 구성](/docs/reference/access-authn-authz/controlling-access/)은
|
||||
클러스터 관리자가 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후
|
||||
고 가용성 지원과 충돌할 수 있다.
|
||||
|
||||
### API에 프로그래밍 방식으로 접근
|
||||
|
||||
쿠버네티스는 공식적으로 [Go](#go-client), [Python](#python-client), [Java](#java-client), [dotnet](#dotnet-client), [Javascript](#javascript-client) 및 [Haskell](#haskell-client) 용 클라이언트 라이브러리를 지원한다. 쿠버네티스 팀이 아닌 작성자가 제공하고 유지 관리하는 다른 클라이언트 라이브러리가 있다. 다른 언어에서 API에 접근하고 인증하는 방법에 대해서는 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 참고한다.
|
||||
|
||||
#### Go 클라이언트 {#go-client}
|
||||
|
||||
* 라이브러리를 얻으려면, 다음 명령을 실행한다. `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>` 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes/client-go/releases](https://github.com/kubernetes/client-go/releases)를 참고한다.
|
||||
* client-go 클라이언트 위에 애플리케이션을 작성한다.
|
||||
|
||||
{{< note >}}
|
||||
|
||||
client-go는 자체 API 오브젝트를 정의하므로, 필요한 경우, 기본 리포지터리가 아닌 client-go에서 API 정의를 가져온다. 예를 들어, `import "k8s.io/client-go/kubernetes"` 가 맞다.
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
Go 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
|
||||
사용할 수 있다. 이 [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다.
|
||||
|
||||
```golang
|
||||
import (
|
||||
"fmt"
|
||||
"k8s.io/apimachinery/pkg/apis/meta/v1"
|
||||
"k8s.io/client-go/kubernetes"
|
||||
"k8s.io/client-go/tools/clientcmd"
|
||||
)
|
||||
|
||||
func main() {
|
||||
// kubeconfig에서 현재 콘텍스트를 사용한다
|
||||
// path-to-kubeconfig -- 예를 들어, /root/.kube/config
|
||||
config, _ := clientcmd.BuildConfigFromFlags("", "<path-to-kubeconfig>")
|
||||
// clientset을 생성한다
|
||||
clientset, _ := kubernetes.NewForConfig(config)
|
||||
// 파드를 나열하기 위해 API에 접근한다
|
||||
pods, _ := clientset.CoreV1().Pods("").List(v1.ListOptions{})
|
||||
fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
|
||||
}
|
||||
```
|
||||
|
||||
애플리케이션이 클러스터에서 파드로 배치된 경우, [파드 내에서 API 접근](#accessing-the-api-from-within-a-pod)을 참고한다.
|
||||
|
||||
#### Python 클라이언트 {#python-client}
|
||||
|
||||
[Python 클라이언트](https://github.com/kubernetes-client/python)를 사용하려면, 다음 명령을 실행한다. `pip install kubernetes` 추가 설치 옵션은 [Python Client Library 페이지](https://github.com/kubernetes-client/python)를 참고한다.
|
||||
|
||||
Python 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
|
||||
사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py)를 참고한다.
|
||||
|
||||
```python
|
||||
from kubernetes import client, config
|
||||
|
||||
config.load_kube_config()
|
||||
|
||||
v1=client.CoreV1Api()
|
||||
print("Listing pods with their IPs:")
|
||||
ret = v1.list_pod_for_all_namespaces(watch=False)
|
||||
for i in ret.items:
|
||||
print("%s\t%s\t%s" % (i.status.pod_ip, i.metadata.namespace, i.metadata.name))
|
||||
```
|
||||
|
||||
#### Java 클라이언트 {#java-client}
|
||||
|
||||
* [Java 클라이언트](https://github.com/kubernetes-client/java)를 설치하려면, 다음을 실행한다.
|
||||
|
||||
```shell
|
||||
# java 라이브러리를 클론한다
|
||||
git clone --recursive https://github.com/kubernetes-client/java
|
||||
|
||||
# 프로젝트 아티팩트, POM 등을 설치한다
|
||||
cd java
|
||||
mvn install
|
||||
```
|
||||
|
||||
어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases)를 참고한다.
|
||||
|
||||
Java 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
|
||||
사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java)를 참고한다.
|
||||
|
||||
```java
|
||||
package io.kubernetes.client.examples;
|
||||
|
||||
import io.kubernetes.client.ApiClient;
|
||||
import io.kubernetes.client.ApiException;
|
||||
import io.kubernetes.client.Configuration;
|
||||
import io.kubernetes.client.apis.CoreV1Api;
|
||||
import io.kubernetes.client.models.V1Pod;
|
||||
import io.kubernetes.client.models.V1PodList;
|
||||
import io.kubernetes.client.util.ClientBuilder;
|
||||
import io.kubernetes.client.util.KubeConfig;
|
||||
import java.io.FileReader;
|
||||
import java.io.IOException;
|
||||
|
||||
/**
|
||||
* 쿠버네티스 클러스터 외부의 애플리케이션에서 Java API를 사용하는 방법에 대한 간단한 예
|
||||
*
|
||||
* <p>이것을 실행하는 가장 쉬운 방법: mvn exec:java
|
||||
* -Dexec.mainClass="io.kubernetes.client.examples.KubeConfigFileClientExample"
|
||||
*
|
||||
*/
|
||||
public class KubeConfigFileClientExample {
|
||||
public static void main(String[] args) throws IOException, ApiException {
|
||||
|
||||
// KubeConfig의 파일 경로
|
||||
String kubeConfigPath = "~/.kube/config";
|
||||
|
||||
// 파일시스템에서 클러스터 외부 구성인 kubeconfig 로드
|
||||
ApiClient client =
|
||||
ClientBuilder.kubeconfig(KubeConfig.loadKubeConfig(new FileReader(kubeConfigPath))).build();
|
||||
|
||||
// 전역 디폴트 api-client를 위에서 정의한 클러스터 내 클라이언트로 설정
|
||||
Configuration.setDefaultApiClient(client);
|
||||
|
||||
// CoreV1Api는 전역 구성에서 디폴트 api-client를 로드
|
||||
CoreV1Api api = new CoreV1Api();
|
||||
|
||||
// CoreV1Api 클라이언트를 호출한다
|
||||
V1PodList list = api.listPodForAllNamespaces(null, null, null, null, null, null, null, null, null);
|
||||
System.out.println("Listing all pods: ");
|
||||
for (V1Pod item : list.getItems()) {
|
||||
System.out.println(item.getMetadata().getName());
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### dotnet 클라이언트 {#dotnet-client}
|
||||
|
||||
[dotnet 클라이언트](https://github.com/kubernetes-client/csharp)를 사용하려면, 다음 명령을 실행한다. `dotnet add package KubernetesClient --version 1.6.1` 추가 설치 옵션은 [dotnet Client Library 페이지](https://github.com/kubernetes-client/csharp)를 참고한다. 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases)를 참고한다.
|
||||
|
||||
dotnet 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
|
||||
사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/csharp/blob/master/examples/simple/PodList.cs)를 참고한다.
|
||||
|
||||
```csharp
|
||||
using System;
|
||||
using k8s;
|
||||
|
||||
namespace simple
|
||||
{
|
||||
internal class PodList
|
||||
{
|
||||
private static void Main(string[] args)
|
||||
{
|
||||
var config = KubernetesClientConfiguration.BuildDefaultConfig();
|
||||
IKubernetes client = new Kubernetes(config);
|
||||
Console.WriteLine("Starting Request!");
|
||||
|
||||
var list = client.ListNamespacedPod("default");
|
||||
foreach (var item in list.Items)
|
||||
{
|
||||
Console.WriteLine(item.Metadata.Name);
|
||||
}
|
||||
if (list.Items.Count == 0)
|
||||
{
|
||||
Console.WriteLine("Empty!");
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### JavaScript 클라이언트 {#javascript-client}
|
||||
|
||||
[JavaScript 클라이언트](https://github.com/kubernetes-client/javascript)를 설치하려면, 다음 명령을 실행한다. `npm install @kubernetes/client-node` 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases)를 참고한다.
|
||||
|
||||
JavaScript 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
|
||||
사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js)를 참고한다.
|
||||
|
||||
```javascript
|
||||
const k8s = require('@kubernetes/client-node');
|
||||
|
||||
const kc = new k8s.KubeConfig();
|
||||
kc.loadFromDefault();
|
||||
|
||||
const k8sApi = kc.makeApiClient(k8s.CoreV1Api);
|
||||
|
||||
k8sApi.listNamespacedPod('default').then((res) => {
|
||||
console.log(res.body);
|
||||
});
|
||||
```
|
||||
|
||||
#### Haskell 클라이언트 {#haskell-client}
|
||||
|
||||
어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/haskell/releases](https://github.com/kubernetes-client/haskell/releases)를 참고한다.
|
||||
|
||||
Haskell 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
|
||||
사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/haskell/blob/master/kubernetes-client/example/App.hs)를 참고한다.
|
||||
|
||||
```haskell
|
||||
exampleWithKubeConfig :: IO ()
|
||||
exampleWithKubeConfig = do
|
||||
oidcCache <- atomically $ newTVar $ Map.fromList []
|
||||
(mgr, kcfg) <- mkKubeClientConfig oidcCache $ KubeConfigFile "/path/to/kubeconfig"
|
||||
dispatchMime
|
||||
mgr
|
||||
kcfg
|
||||
(CoreV1.listPodForAllNamespaces (Accept MimeJSON))
|
||||
>>= print
|
||||
```
|
||||
|
||||
|
||||
### 파드 내에서 API에 접근 {#accessing-the-api-from-within-a-pod}
|
||||
|
||||
파드 내에서 API에 접근할 때, API 서버를 찾아 인증하는 것은
|
||||
위에서 설명한 외부 클라이언트 사례와 약간 다르다.
|
||||
|
||||
파드에서 쿠버네티스 API를 사용하는 가장 쉬운 방법은
|
||||
공식 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이다. 이러한
|
||||
라이브러리는 API 서버를 자동으로 감지하고 인증할 수 있다.
|
||||
|
||||
#### 공식 클라이언트 라이브러리 사용
|
||||
|
||||
파드 내에서, 쿠버네티스 API에 연결하는 권장 방법은 다음과 같다.
|
||||
|
||||
- Go 클라이언트의 경우, 공식 [Go 클라이언트 라이브러리](https://github.com/kubernetes/client-go/)를 사용한다.
|
||||
`rest.InClusterConfig()` 기능은 API 호스트 검색과 인증을 자동으로 처리한다.
|
||||
[여기 예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)를 참고한다.
|
||||
|
||||
- Python 클라이언트의 경우, 공식 [Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python/)를 사용한다.
|
||||
`config.load_incluster_config()` 기능은 API 호스트 검색과 인증을 자동으로 처리한다.
|
||||
[여기 예제](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py)를 참고한다.
|
||||
|
||||
- 사용할 수 있는 다른 라이브러리가 많이 있다. [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 페이지를 참고한다.
|
||||
|
||||
각각의 경우, 파드의 서비스 어카운트 자격 증명은 API 서버와
|
||||
안전하게 통신하는 데 사용된다.
|
||||
|
||||
#### REST API에 직접 접근
|
||||
|
||||
파드에서 실행되는 동안, 쿠버네티스 apiserver는 `default` 네임스페이스에서 `kubernetes`라는
|
||||
서비스를 통해 접근할 수 있다. 따라서, 파드는 `kubernetes.default.svc`
|
||||
호스트 이름을 사용하여 API 서버를 쿼리할 수 있다. 공식 클라이언트 라이브러리는
|
||||
이를 자동으로 수행한다.
|
||||
|
||||
API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/user-guide/service-accounts)
|
||||
자격 증명을 사용하는 것이다. 기본적으로, 파드는
|
||||
서비스 어카운트와 연결되어 있으며, 해당 서비스 어카운트에 대한 자격 증명(토큰)은
|
||||
해당 파드에 있는 각 컨테이너의 파일시스템 트리의
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/token` 에 있다.
|
||||
|
||||
사용 가능한 경우, 인증서 번들은 각 컨테이너의
|
||||
파일시스템 트리의 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` 에 배치되며,
|
||||
API 서버의 제공 인증서를 확인하는 데 사용해야 한다.
|
||||
|
||||
마지막으로, 네임스페이스가 지정된 API 작업에 사용되는 기본 네임스페이스는 각 컨테이너의
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 에 있는 파일에 배치된다.
|
||||
|
||||
#### kubectl 프록시 사용
|
||||
|
||||
공식 클라이언트 라이브러리 없이 API를 쿼리하려면, 파드에서
|
||||
새 사이드카 컨테이너의 [명령](/ko/docs/tasks/inject-data-application/define-command-argument-container/)으로
|
||||
`kubectl proxy` 를 실행할 수 있다. 이런 식으로, `kubectl proxy` 는
|
||||
API를 인증하고 이를 파드의 `localhost` 인터페이스에 노출시켜서, 파드의
|
||||
다른 컨테이너가 직접 사용할 수 있도록 한다.
|
||||
|
||||
#### 프록시를 사용하지 않고 접근
|
||||
|
||||
인증 토큰을 API 서버에 직접 전달하여 kubectl 프록시 사용을
|
||||
피할 수 있다. 내부 인증서는 연결을 보호한다.
|
||||
|
||||
```shell
|
||||
# 내부 API 서버 호스트 이름을 가리킨다
|
||||
APISERVER=https://kubernetes.default.svc
|
||||
|
||||
# ServiceAccount 토큰 경로
|
||||
SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
|
||||
|
||||
# 이 파드의 네임스페이스를 읽는다
|
||||
NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
|
||||
|
||||
# ServiceAccount 베어러 토큰을 읽는다
|
||||
TOKEN=$(cat ${SERVICEACCOUNT}/token)
|
||||
|
||||
# 내부 인증 기관(CA)을 참조한다
|
||||
CACERT=${SERVICEACCOUNT}/ca.crt
|
||||
|
||||
# TOKEN으로 API를 탐색한다
|
||||
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
|
||||
```
|
||||
|
||||
출력은 다음과 비슷하다.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,134 @@
|
||||
---
|
||||
title: 클러스터에서 실행되는 서비스에 접근
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
이 페이지는 쿠버네티스 클러스터에서 실행되는 서비스에 연결하는 방법을 보여준다.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 클러스터에서 실행되는 서비스에 접근
|
||||
|
||||
쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), [파드](/ko/docs/concepts/workloads/pods/pod/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
|
||||
고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수
|
||||
없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서
|
||||
도달할 수 없다.
|
||||
|
||||
### 연결하는 방법
|
||||
|
||||
클러스터 외부에서 노드, 파드 및 서비스에 연결하기 위한 몇 가지 옵션이 있다.
|
||||
|
||||
- 퍼블릭 IP를 통해 서비스에 접근한다.
|
||||
- `NodePort` 또는 `LoadBalancer` 타입의 서비스를 사용하여 해당 서비스를 클러스터 외부에서
|
||||
접근할 수 있게 한다. [서비스](/ko/docs/concepts/services-networking/service/)와
|
||||
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참고한다.
|
||||
- 클러스터 환경에 따라, 서비스는 단지 회사 네트워크에 노출되기도 하며,
|
||||
인터넷에 노출되는 경우도 있다. 노출되는 서비스가 안전한지 생각한다.
|
||||
자체 인증을 수행하는가?
|
||||
- 서비스 뒤에 파드를 배치한다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면,
|
||||
파드에 고유한 레이블을 배치하고 이 레이블을 선택하는 새 서비스를 생성한다.
|
||||
- 대부분의 경우, 애플리케이션 개발자가 nodeIP를 통해 노드에 직접
|
||||
접근할 필요는 없다.
|
||||
- 프록시 작업(Proxy Verb)을 사용하여 서비스, 노드 또는 파드에 접근한다.
|
||||
- 원격 서비스에 접근하기 전에 apiserver 인증과 권한 부여를 수행한다.
|
||||
서비스가 인터넷에 노출되거나, 노드 IP의 포트에 접근하거나, 디버깅하기에
|
||||
충분히 안전하지 않은 경우 사용한다.
|
||||
- 프록시는 일부 웹 애플리케이션에 문제를 일으킬 수 있다.
|
||||
- HTTP/HTTPS에서만 작동한다.
|
||||
- [여기](#apiserver-프록시-url-수동-구성)에 설명되어 있다.
|
||||
- 클러스터의 노드 또는 파드에서 접근한다.
|
||||
- 파드를 실행한 다음, [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 셸에 연결한다.
|
||||
해당 셸에서 다른 노드, 파드 및 서비스에 연결한다.
|
||||
- 일부 클러스터는 클러스터의 노드로 ssh를 통해 접근하는 것을 허용한다. 거기에서 클러스터 서비스에
|
||||
접근할 수 있다. 이것은 비표준 방법이며, 일부 클러스터에서는 작동하지만 다른 클러스터에서는
|
||||
작동하지 않는다. 브라우저 및 기타 도구가 설치되거나 설치되지 않을 수 있다. 클러스터 DNS가 작동하지 않을 수도 있다.
|
||||
|
||||
### 빌트인 서비스 검색
|
||||
|
||||
일반적으로, kube-system에 의해 클러스터에서 시작되는 몇 가지 서비스가 있다. `kubectl cluster-info` 명령을
|
||||
사용하여 이들의 목록을 얻는다.
|
||||
|
||||
```shell
|
||||
kubectl cluster-info
|
||||
```
|
||||
|
||||
출력은 다음과 비슷하다.
|
||||
|
||||
```
|
||||
Kubernetes master is running at https://104.197.5.247
|
||||
elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
|
||||
kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
|
||||
kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
|
||||
grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
|
||||
heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
|
||||
```
|
||||
|
||||
각 서비스에 접근하기 위한 프록시-작업 URL이 표시된다.
|
||||
예를 들어, 이 클러스터에는 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 로
|
||||
접근할 수 있는 (Elasticsearch를 사용한) 클러스터 수준 로깅이 활성화되어 있다. 적합한 자격 증명이 전달되는 경우나 kubectl proxy를 통해 도달할 수 있다. 예를 들어 다음의 URL에서 확인할 수 있다.
|
||||
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
|
||||
|
||||
{{< note >}}
|
||||
자격 증명을 전달하거나 kubectl proxy를 사용하는 방법은 [쿠버네티스 API를 사용하여 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
#### apiserver 프록시 URL 수동 구성
|
||||
|
||||
위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 단순히 서비스의 프록시 URL에 추가하면 된다.
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy`
|
||||
|
||||
포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다.
|
||||
|
||||
##### 예제
|
||||
|
||||
* Elasticsearch 서비스 엔드포인트 `_search?q=user:kimchy` 에 접근하려면, 다음을 사용한다.
|
||||
|
||||
```
|
||||
http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
|
||||
```
|
||||
|
||||
* Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true` 에 접근하려면, 다음을 사용한다.
|
||||
|
||||
```
|
||||
https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true
|
||||
```
|
||||
|
||||
상태 정보는 다음과 비슷하다.
|
||||
|
||||
```json
|
||||
{
|
||||
"cluster_name" : "kubernetes_logging",
|
||||
"status" : "yellow",
|
||||
"timed_out" : false,
|
||||
"number_of_nodes" : 1,
|
||||
"number_of_data_nodes" : 1,
|
||||
"active_primary_shards" : 5,
|
||||
"active_shards" : 5,
|
||||
"relocating_shards" : 0,
|
||||
"initializing_shards" : 0,
|
||||
"unassigned_shards" : 5
|
||||
}
|
||||
```
|
||||
|
||||
* *https* Elasticsearch 서비스 상태 정보 `_cluster/health?pretty=true` 에 접근하려면, 다음을 사용한다.
|
||||
|
||||
```
|
||||
https://104.197.5.247/api/v1/namespaces/kube-system/services/https:elasticsearch-logging/proxy/_cluster/health?pretty=true
|
||||
```
|
||||
|
||||
#### 웹 브라우저를 사용하여 클러스터에서 실행되는 서비스에 접근
|
||||
|
||||
브라우저의 주소 표시줄에 apiserver 프록시 URL을 넣을 수 있다. 그러나,
|
||||
|
||||
- 웹 브라우저는 일반적으로 토큰을 전달할 수 없으므로, 기본 (비밀번호) 인증을 사용해야 할 수도 있다. Apiserver는 기본 인증을 수락하도록 구성할 수 있지만,
|
||||
클러스터는 기본 인증을 수락하도록 구성되지 않을 수 있다.
|
||||
- 일부 웹 앱, 특히 프록시 경로 접두사를 인식하지 못하는 방식으로 URL을 구성하는 클라이언트 측 자바스크립트가 있는
|
||||
웹 앱이 작동하지 않을 수 있다.
|
||||
@@ -4,7 +4,7 @@ content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝
|
||||
이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝
|
||||
하는데 사용되는 기본 스토리지 클래스를 변경하는 방법을 보여준다.
|
||||
|
||||
|
||||
@@ -20,21 +20,21 @@ content_type: task
|
||||
|
||||
## 왜 기본 스토리지 클래스를 변경하는가?
|
||||
|
||||
설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존
|
||||
스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정
|
||||
스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를
|
||||
설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존
|
||||
스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정
|
||||
스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를
|
||||
동적으로 프로비저닝 하기 위해 사용된다.
|
||||
더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#class-1)를
|
||||
더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)를
|
||||
보자.
|
||||
|
||||
미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지
|
||||
않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할
|
||||
수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화
|
||||
미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지
|
||||
않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할
|
||||
수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화
|
||||
하여 스토리지의 동적 프로비저닝을 방지할 수 있다.
|
||||
|
||||
단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인
|
||||
애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자
|
||||
및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자.
|
||||
단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인
|
||||
애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자
|
||||
및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자.
|
||||
|
||||
## 기본 스토리지클래스 변경하기
|
||||
|
||||
@@ -56,7 +56,7 @@ content_type: task
|
||||
|
||||
1. 기본 스토리지클래스를 기본값이 아닌 것으로 표시한다.
|
||||
|
||||
기본 스토리지클래스에는
|
||||
기본 스토리지클래스에는
|
||||
`storageclass.kubernetes.io/is-default-class` 의 값이 `true` 로 설정되어 있다.
|
||||
다른 값이거나 어노테이션이 없을 경우 `false` 로 처리된다.
|
||||
|
||||
|
||||
@@ -5,9 +5,9 @@ content_type: concept
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성,
|
||||
클러스터의 마스터와 워커 노드들의 업그레이드,
|
||||
노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의
|
||||
이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성,
|
||||
클러스터의 마스터와 워커 노드들의 업그레이드,
|
||||
노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의
|
||||
쿠버네티스 API 버전 업그레이드.
|
||||
|
||||
|
||||
@@ -25,17 +25,17 @@ content_type: concept
|
||||
|
||||
### Azure Kubernetes Service (AKS) 클러스터 업그레이드
|
||||
|
||||
Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는
|
||||
Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는
|
||||
현재 사용자가 직접 시작하는 방식이며 [Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)에 설명되어 있다.
|
||||
|
||||
### Google Compute Engine 클러스터 업그레이드
|
||||
|
||||
Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고
|
||||
재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해
|
||||
Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고
|
||||
재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해
|
||||
동일한 Persistent Disk(PD)를 유지한다.
|
||||
|
||||
GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는
|
||||
순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은
|
||||
GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는
|
||||
순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은
|
||||
레플리케이션 컨트롤러에 의해서 제어되거나, 롤 아웃 후에 수작업으로 재생성되어야 한다.
|
||||
|
||||
open source Google Compute Engine(GCE) 클러스터 업그레이드는 `cluster/gce/upgrade.sh` 스크립트로 제어한다.
|
||||
@@ -81,7 +81,7 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레
|
||||
|
||||
## 클러스터 크기 재조정
|
||||
|
||||
[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다.
|
||||
[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다.
|
||||
[Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면 `Compute > Compute Engine > Instance groups > your group > Edit group`에서 인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다.
|
||||
|
||||
```shell
|
||||
@@ -99,23 +99,23 @@ Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터
|
||||
|
||||
### 클러스터 오토스케일링
|
||||
|
||||
GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로
|
||||
GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로
|
||||
재조정하도록 클러스터를 구성할 수 있다.
|
||||
|
||||
[컴퓨트 리소스](/docs/concepts/configuration/manage-compute-resources-container/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다.
|
||||
이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다.
|
||||
여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는
|
||||
[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다.
|
||||
이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다.
|
||||
여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는
|
||||
다른 파드들이 종료될 때까지 기다리거나 신규 노드가 추가될 때까지 기다린다.
|
||||
|
||||
Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를
|
||||
Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를
|
||||
추가하는 것이 도움이 되는지를 체크한다. 만약 도움이 된다면 대기중인 파드들을 수용하기 위해 클러스터의 크기를 재조정한다.
|
||||
|
||||
Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안
|
||||
Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안
|
||||
더 이상 필요하지 않다는 것을 확인했을 때 클러스터를 스케일 다운하기도 한다.
|
||||
|
||||
Cluster autoscaler는 인스턴스 그룹(GCE)이나 노드 풀(Google Kubernetes Engine) 단위로 구성된다.
|
||||
|
||||
GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다.
|
||||
GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다.
|
||||
cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설정해야 한다.
|
||||
|
||||
* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - true로 설정되면 cluster autoscaler를 활성화한다.
|
||||
@@ -128,8 +128,8 @@ cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설
|
||||
KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의
|
||||
생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을
|
||||
Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의
|
||||
생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을
|
||||
전달하여 cluster autoscaler를 구성할 수 있다.
|
||||
|
||||
예제:
|
||||
@@ -144,17 +144,17 @@ gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=
|
||||
|
||||
**Cluster autoscaler는 노드가 수작업으로 변경(예. kubectl을 통해 레이블을 추가)되는 경우를 예상하지 않는데, 동일한 인스턴스 그룹 내의 신규 노드들에 이 속성들이 전파되지 않을 것이기 때문이다.**
|
||||
|
||||
cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은
|
||||
autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
|
||||
cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은
|
||||
autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
|
||||
문서를 참조하기를 바란다.
|
||||
|
||||
## 노드 유지보수
|
||||
|
||||
(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면,
|
||||
Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면
|
||||
(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.)
|
||||
노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는
|
||||
레플리카 셋 (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이
|
||||
(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면,
|
||||
Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면
|
||||
(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.)
|
||||
노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는
|
||||
레플리카셋(ReplicaSet) (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이
|
||||
복제된 상황에서 모든 노드들이 동시에 다운되지 않는다고 가정했을 때, 별다른 조작없이 업데이트를 진행할 수 있다.
|
||||
|
||||
만약 업그레이드 과정을 상세하게 통제하기를 원한다면, 다음 워크플로우를 사용할 수 있다.
|
||||
@@ -167,9 +167,9 @@ kubectl drain $NODENAME
|
||||
|
||||
이렇게하면 파드가 종료되는 동안 신규 파드들이 해당 노드에 스케줄되는 것을 방지한다.
|
||||
|
||||
레플리카 셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다.
|
||||
레플리카셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다.
|
||||
|
||||
레플리카 셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다.
|
||||
레플리카셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다.
|
||||
|
||||
해당 노드에 유지보수 작업을 수행한다.
|
||||
|
||||
@@ -179,8 +179,8 @@ kubectl drain $NODENAME
|
||||
kubectl uncordon $NODENAME
|
||||
```
|
||||
|
||||
해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가
|
||||
자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면;
|
||||
해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가
|
||||
자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면;
|
||||
이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라.
|
||||
|
||||
## 고급 주제들
|
||||
@@ -199,15 +199,15 @@ kubectl uncordon $NODENAME
|
||||
|
||||
### 클러스터에서 API 버전을 ON/OFF 하기
|
||||
|
||||
특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를
|
||||
전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다.
|
||||
예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다.
|
||||
특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를
|
||||
전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다.
|
||||
예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다.
|
||||
이 플래그들을 위해 레거시 API들은 명확하게 사용중단된 API들이다.(예. `v1beta3`)
|
||||
|
||||
### 클러스터에서 스토리지 API 버전을 변경
|
||||
|
||||
클러스터 내에서 활성화된 쿠버네티스 리소스들의 클러스터의 내부 표현을 위해 디스크에 저장된 객체들은 특정 버전의 API를 사용하여 작성된다.
|
||||
지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이
|
||||
지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이
|
||||
쿠버네티스 API 서버에서 더 이상 해독되거나 사용할 수 없게 될 것이다.
|
||||
|
||||
### 구성 파일을 신규 API 버전으로 변경
|
||||
@@ -219,5 +219,3 @@ kubectl convert -f pod.yaml --output-version v1
|
||||
```
|
||||
|
||||
옵션에 대한 상세 정보는 [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) 커맨드의 사용법을 참조하기를 바란다.
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,206 @@
|
||||
---
|
||||
title: 노드에 대한 확장 리소스 알리기
|
||||
content_type: task
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 노드의 확장 리소스를 지정하는 방법을 보여준다.
|
||||
확장 리소스를 통해 클러스터 관리자는 쿠버네티스에게
|
||||
알려지지 않은 노드-레벨 리소스를 알릴 수 있다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 노드의 이름을 확인한다
|
||||
|
||||
```shell
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
이 연습에 사용할 노드 중 하나를 선택한다.
|
||||
|
||||
## 노드 중 하나에 새로운 확장 리소스를 알린다
|
||||
|
||||
노드에서 새로운 확장 리소스를 알리려면, 쿠버네티스 API 서버에
|
||||
HTTP PATCH 요청을 보낸다. 예를 들어, 노드 중 하나에 4개의 동글(dongle)이 있다고
|
||||
가정한다. 다음은 노드에 4개의 동글 리소스를 알리는 PATCH 요청의
|
||||
예이다.
|
||||
|
||||
```shell
|
||||
PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
|
||||
Accept: application/json
|
||||
Content-Type: application/json-patch+json
|
||||
Host: k8s-master:8080
|
||||
|
||||
[
|
||||
{
|
||||
"op": "add",
|
||||
"path": "/status/capacity/example.com~1dongle",
|
||||
"value": "4"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
참고로 쿠버네티스는 동글이 무엇인지 또는 동글이 무엇을 위한 것인지 알 필요가 없다.
|
||||
위의 PATCH 요청은 노드에 동글이라고 하는 네 가지 항목이 있음을
|
||||
쿠버네티스에 알려준다.
|
||||
|
||||
쿠버네티스 API 서버에 요청을 쉽게 보낼 수 있도록 프록시를 시작한다.
|
||||
|
||||
```shell
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
다른 명령 창에서 HTTP PATCH 요청을 보낸다.
|
||||
`<your-node-name>` 을 노드의 이름으로 바꾼다.
|
||||
|
||||
```shell
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH \
|
||||
--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \
|
||||
http://localhost:8001/api/v1/nodes/<your-node-name>/status
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
이전 요청에서 `~1` 은 패치 경로의 / 문자에 대한
|
||||
인코딩이다. JSON-Patch의 작업 경로값은 JSON-Pointer로
|
||||
해석된다. 자세한 내용은 [IETF RFC 6901](https://tools.ietf.org/html/rfc6901)의
|
||||
섹션 3을 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
출력은 노드가 4개의 동글 용량을 가졌음을 나타낸다.
|
||||
|
||||
```
|
||||
"capacity": {
|
||||
"cpu": "2",
|
||||
"memory": "2049008Ki",
|
||||
"example.com/dongle": "4",
|
||||
```
|
||||
|
||||
노드의 정보를 확인한다.
|
||||
|
||||
```
|
||||
kubectl describe node <your-node-name>
|
||||
```
|
||||
|
||||
다시 한 번, 출력에 동글 리소스가 표시된다.
|
||||
|
||||
```yaml
|
||||
Capacity:
|
||||
cpu: 2
|
||||
memory: 2049008Ki
|
||||
example.com/dongle: 4
|
||||
```
|
||||
|
||||
이제, 애플리케이션 개발자는 특정 개수의 동글을 요청하는 파드를
|
||||
만들 수 있다. [컨테이너에 확장 리소스 할당하기](/docs/tasks/configure-pod-container/extended-resource/)를
|
||||
참고한다.
|
||||
|
||||
## 토론
|
||||
|
||||
확장 리소스는 메모리 및 CPU 리소스와 비슷하다. 예를 들어,
|
||||
노드에서 실행 중인 모든 컴포넌트가 공유할 특정 양의 메모리와 CPU가
|
||||
노드에 있는 것처럼, 노드에서 실행 중인 모든 컴포넌트가
|
||||
특정 동글을 공유할 수 있다. 또한 애플리케이션 개발자가
|
||||
특정 양의 메모리와 CPU를 요청하는 파드를 생성할 수 있는 것처럼, 특정
|
||||
동글을 요청하는 파드를 생성할 수 있다.
|
||||
|
||||
확장 리소스는 쿠버네티스에게 불투명하다. 쿠버네티스는 그것들이
|
||||
무엇인지 전혀 모른다. 쿠버네티스는 노드에 특정 개수의 노드만
|
||||
있다는 것을 알고 있다. 확장 리소스는 정수로 알려야
|
||||
한다. 예를 들어, 노드는 4.5개의 동글이 아닌, 4개의 동글을 알릴 수 있다.
|
||||
|
||||
### 스토리지 예제
|
||||
|
||||
노드에 800GiB의 특별한 종류의 디스크 스토리지가 있다고 가정한다.
|
||||
example.com/special-storage와 같은 특별한 스토리지의 이름을 생성할 수 있다.
|
||||
그런 다음 특정 크기, 100GiB의 청크로 알릴 수 있다. 이 경우,
|
||||
노드에는 example.com/special-storage 유형의 8가지 리소스가 있다고
|
||||
알린다.
|
||||
|
||||
```yaml
|
||||
Capacity:
|
||||
...
|
||||
example.com/special-storage: 8
|
||||
```
|
||||
|
||||
이 특별한 스토리지에 대한 임의 요청을 허용하려면,
|
||||
1바이트 크기의 청크로 특별한 스토리지를 알릴 수 있다. 이 경우, example.com/special-storage 유형의
|
||||
800Gi 리소스를 알린다.
|
||||
|
||||
```yaml
|
||||
Capacity:
|
||||
...
|
||||
example.com/special-storage: 800Gi
|
||||
```
|
||||
|
||||
그런 다음 컨테이너는 최대 800Gi의 임의 바이트 수의 특별한 스토리지를 요청할 수 있다.
|
||||
|
||||
## 정리
|
||||
|
||||
다음은 노드에서 동글 알림을 제거하는 PATCH 요청이다.
|
||||
|
||||
```
|
||||
PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
|
||||
Accept: application/json
|
||||
Content-Type: application/json-patch+json
|
||||
Host: k8s-master:8080
|
||||
|
||||
[
|
||||
{
|
||||
"op": "remove",
|
||||
"path": "/status/capacity/example.com~1dongle",
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
쿠버네티스 API 서버에 요청을 쉽게 보낼 수 있도록 프록시를 시작한다.
|
||||
|
||||
```shell
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
다른 명령 창에서 HTTP PATCH 요청을 보낸다.
|
||||
`<your-node-name>`을 노드의 이름으로 바꾼다.
|
||||
|
||||
```shell
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH \
|
||||
--data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \
|
||||
http://localhost:8001/api/v1/nodes/<your-node-name>/status
|
||||
```
|
||||
|
||||
동글 알림이 제거되었는지 확인한다.
|
||||
|
||||
```
|
||||
kubectl describe node <your-node-name> | grep dongle
|
||||
```
|
||||
|
||||
(출력이 보이지 않아야 함)
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
### 애플리케이션 개발자를 위한 문서
|
||||
|
||||
* [컨테이너에 확장 리소스 할당하기](/docs/tasks/configure-pod-container/extended-resource/)
|
||||
|
||||
### 클러스터 관리자를 위한 문서
|
||||
|
||||
* [네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
|
||||
* [네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Windows 노드 추가
|
||||
title: 윈도우 노드 추가
|
||||
min-kubernetes-server-version: 1.17
|
||||
content_type: tutorial
|
||||
weight: 30
|
||||
@@ -9,7 +9,7 @@ weight: 30
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
쿠버네티스를 사용하여 리눅스와 Windows 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 Windows에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 Windows 노드를 클러스터에 등록하는 방법을 보여준다.
|
||||
쿠버네티스를 사용하여 리눅스와 윈도우 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 윈도우에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 윈도우 노드를 클러스터에 등록하는 방법을 보여준다.
|
||||
|
||||
|
||||
|
||||
@@ -17,8 +17,8 @@ weight: 30
|
||||
## {{% heading "prerequisites" %}}
|
||||
{{< version-check >}}
|
||||
|
||||
* Windows 컨테이너를 호스팅하는 Windows 노드를 구성하려면
|
||||
[Windows Server 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) 이상이 필요하다.
|
||||
* 윈도우 컨테이너를 호스팅하는 윈도우 노드를 구성하려면
|
||||
[윈도우 서버 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/) 참고)가 필요하다.
|
||||
@@ -29,15 +29,15 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
|
||||
* 클러스터에 Windows 노드 등록
|
||||
* 리눅스 및 Windows의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성
|
||||
* 클러스터에 윈도우 노드 등록
|
||||
* 리눅스 및 윈도우의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## 시작하기: 클러스터에 Windows 노드 추가
|
||||
## 시작하기: 클러스터에 윈도우 노드 추가
|
||||
|
||||
### 네트워킹 구성
|
||||
|
||||
@@ -75,7 +75,7 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
|
||||
}
|
||||
```
|
||||
|
||||
{{< note >}}리눅스의 플란넬이 Windows의 플란넬과 상호 운용되도록 하려면 VNI를 4096으로, 포트를 4789로 설정해야 한다. 이 필드들에 대한 설명은 [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)를
|
||||
{{< 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 >}}
|
||||
@@ -102,9 +102,9 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
|
||||
kube-system kube-flannel-ds-54954 1/1 Running 0 1m
|
||||
```
|
||||
|
||||
1. Windows 플란넬 및 kube-proxy 데몬셋 추가
|
||||
1. 윈도우 플란넬 및 kube-proxy 데몬셋 추가
|
||||
|
||||
이제 Windows 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한
|
||||
이제 윈도우 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한
|
||||
kube-proxy 버전을 얻으려면, 이미지의 태그를
|
||||
대체해야 한다. 다음의 예시는 쿠버네티스 {{< param "fullversion" >}}의 사용법을 보여주지만,
|
||||
사용자의 배포에 맞게 버전을 조정해야 한다.
|
||||
@@ -118,7 +118,7 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Windows 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다.
|
||||
윈도우 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다.
|
||||
|
||||
```powershell
|
||||
wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
|
||||
@@ -134,14 +134,14 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
|
||||
|
||||
|
||||
|
||||
### Windows 워커 노드 조인(joining)
|
||||
### 윈도우 워커 노드 조인(joining)
|
||||
{{< note >}}
|
||||
`Containers` 기능을 설치하고 도커를 설치해야 한다.
|
||||
[Windows Server에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다.
|
||||
[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Windows 섹션의 모든 코드 스니펫(snippet)은 Windows 워커 노드의
|
||||
윈도우 섹션의 모든 코드 스니펫(snippet)은 윈도우 워커 노드의
|
||||
높은 권한(관리자)이 있는 PowerShell 환경에서 실행해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -160,7 +160,7 @@ Windows 섹션의 모든 코드 스니펫(snippet)은 Windows 워커 노드의
|
||||
|
||||
|
||||
#### 설치 확인
|
||||
이제 다음을 실행하여 클러스터에서 Windows 노드를 볼 수 있다.
|
||||
이제 다음을 실행하여 클러스터에서 윈도우 노드를 볼 수 있다.
|
||||
|
||||
```bash
|
||||
kubectl get nodes -o wide
|
||||
@@ -180,6 +180,6 @@ flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
- [Windows kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
|
||||
- [윈도우 kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
|
||||
|
||||
|
||||
|
||||
@@ -242,7 +242,7 @@ min-kubernetes-server-version: 1.18
|
||||
- CNI 제공자 플러그인을 수동으로 업그레이드한다.
|
||||
|
||||
CNI(컨테이너 네트워크 인터페이스) 제공자는 자체 업그레이드 지침을 따를 수 있다.
|
||||
[애드온](/docs/concepts/cluster-administration/addons/) 페이지에서
|
||||
[애드온](/ko/docs/concepts/cluster-administration/addons/) 페이지에서
|
||||
사용하는 CNI 제공자를 찾고 추가 업그레이드 단계가 필요한지 여부를 확인한다.
|
||||
|
||||
CNI 제공자가 데몬셋(DaemonSet)으로 실행되는 경우 추가 컨트롤 플레인 노드에는 이 단계가 필요하지 않다.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Windows 노드 업그레이드
|
||||
title: 윈도우 노드 업그레이드
|
||||
min-kubernetes-server-version: 1.17
|
||||
content_type: task
|
||||
weight: 40
|
||||
@@ -9,7 +9,7 @@ weight: 40
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
이 페이지는 [kubeadm으로 생성된](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) Windows 노드를 업그레이드하는 방법을 설명한다.
|
||||
이 페이지는 [kubeadm으로 생성된](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) 윈도우 노드를 업그레이드하는 방법을 설명한다.
|
||||
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ weight: 40
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* [남은 kubeadm 클러스터를 업그레이드하는 프로세스](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)에
|
||||
익숙해져야 한다. Windows 노드를
|
||||
익숙해져야 한다. 윈도우 노드를
|
||||
업그레이드하기 전에 컨트롤 플레인 노드를 업그레이드해야 한다.
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ weight: 40
|
||||
|
||||
### kubeadm 업그레이드
|
||||
|
||||
1. Windows 노드에서, kubeadm을 업그레이드한다.
|
||||
1. 윈도우 노드에서, kubeadm을 업그레이드한다.
|
||||
|
||||
```powershell
|
||||
# replace {{< param "fullversion" >}} with your desired version
|
||||
@@ -56,7 +56,7 @@ weight: 40
|
||||
|
||||
### kubelet 구성 업그레이드
|
||||
|
||||
1. Windows 노드에서, 다음의 명령을 호출하여 새 kubelet 구성을 동기화한다.
|
||||
1. 윈도우 노드에서, 다음의 명령을 호출하여 새 kubelet 구성을 동기화한다.
|
||||
|
||||
```powershell
|
||||
kubeadm upgrade node
|
||||
@@ -64,7 +64,7 @@ weight: 40
|
||||
|
||||
### kubelet 업그레이드
|
||||
|
||||
1. Windows 노드에서, kubelet을 업그레이드하고 다시 시작한다.
|
||||
1. 윈도우 노드에서, kubelet을 업그레이드하고 다시 시작한다.
|
||||
|
||||
```powershell
|
||||
stop-service kubelet
|
||||
|
||||
+1
-4
@@ -265,7 +265,4 @@ kubectl delete namespace constraints-cpu-example
|
||||
|
||||
* [컨테이너와 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
@@ -188,6 +188,4 @@ kubectl delete namespace default-cpu-example
|
||||
|
||||
* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
+1
-3
@@ -265,6 +265,4 @@ kubectl delete namespace constraints-mem-example
|
||||
|
||||
* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
+1
-5
@@ -196,8 +196,4 @@ kubectl delete namespace default-mem-example
|
||||
|
||||
* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
|
||||
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
+1
-3
@@ -172,6 +172,4 @@ kubectl delete namespace quota-mem-cpu-example
|
||||
|
||||
* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
@@ -133,11 +133,4 @@ kubectl delete namespace quota-pod-example
|
||||
|
||||
* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
+1
-1
@@ -48,7 +48,7 @@ Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함
|
||||
간단한 ``올인원`` YAML 파일로 배포할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
|
||||
```
|
||||
```
|
||||
configmap/cilium-config created
|
||||
|
||||
-4
@@ -39,7 +39,3 @@ Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/roman
|
||||
|
||||
|
||||
로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user