Apply suggestions from code review
Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com>
This commit is contained in:
Jerry Park
GitHub
parent
1e50590bc4
commit
858e73a417
|
|
@ -118,8 +118,8 @@ containerd를 설치한다.
|
|||
{{% /tab %}}
|
||||
{{% tab name="Windows (PowerShell)" %}}
|
||||
|
||||
PowerShell 세션을 시작하고 `$Version`을 원하는 버전(예: `$Version:1.4.3`)으로
|
||||
설정한 후 다음 명령을 실행한다.
|
||||
PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로
|
||||
설정(예: `$Version:1.4.3`)한 후 다음 명령을 실행한다.
|
||||
|
||||
1. containerd 다운로드
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ weight: 75
|
|||
* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너
|
||||
모두 비슷한 방식이라는 것이 중요하다.
|
||||
[Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다.
|
||||
아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다.
|
||||
아래 단원의 예시를 통해 윈도우 컨테이너와 좀 더 빨리 친숙해질 수 있다.
|
||||
|
||||
## 시작하기: 윈도우 컨테이너 배포하기
|
||||
|
||||
|
|
@ -99,17 +99,17 @@ spec:
|
|||
|
||||
1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.
|
||||
|
||||
* 윈도우 노드에 파드당 두 컨테이너, `docker ps`를 사용한다.
|
||||
* 리눅스 마스터에서 나열된 두 파드, `kubectl get pods`를 사용한다.
|
||||
* 네트워크를 통한 노드에서 파드 간에 통신, 리눅스 마스터에서 `curl`을
|
||||
* 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, `docker ps`를 사용한다.
|
||||
* 리눅스 마스터에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
|
||||
* 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터에서 `curl`을
|
||||
파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
|
||||
* 파드와 파드 간에 통신, `docker exec` 나 `kubectl exec`를 이용해 파드 간에
|
||||
핑(ping)한다(윈도우 노드를 여럿 가지고 있다면 호스트를 달리하며).
|
||||
* 서비스와 파드 간에 통신, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스
|
||||
IP 주소(`kubectl get services`로 보여지는)로 실행한다.
|
||||
* 서비스 검색(discovery), 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다.
|
||||
* 인바운드 연결, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
|
||||
* 아웃바운드 연결, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.
|
||||
* 파드 간 통신이 되는지 확인하려면, `docker exec` 나 `kubectl exec`를 이용해 파드 간에
|
||||
핑(ping)한다(윈도우 노드가 2대 이상이라면, 서로 다른 노드에 있는 파드 간 통신도 확인할 수 있다).
|
||||
* 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스
|
||||
IP 주소(`kubectl get services`로 볼 수 있는)로 실행한다.
|
||||
* 서비스 검색(discovery)이 되는지 확인하려면, 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다.
|
||||
* 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
|
||||
* 아웃바운드 연결이 되는지 확인하려면, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.
|
||||
|
||||
{{< note >}}
|
||||
윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다.
|
||||
|
|
@ -122,8 +122,8 @@ spec:
|
|||
|
||||
로그는 가시성의 중요한 요소이다. 로그는 사용자가 워크로드의 운영측면을
|
||||
파악할 수 있도록 하며 문제 해결의 핵심 요소이다.
|
||||
윈도우 컨테이너와 워크로드 내의 윈도우 컨테이너가 리눅스 컨테이너와는 다르게 동작하기 때문에,
|
||||
사용자가 로그를 수집하는 데 어려움을 겪었기에 운영 가시성이 제한되었다.
|
||||
윈도우 컨테이너, 그리고 윈도우 컨테이너 내의 워크로드는 리눅스 컨테이너와는 다르게 동작하기 때문에,
|
||||
사용자가 로그를 수집하기 어려웠고 이로 인해 운영 가시성이 제한되어 왔다.
|
||||
예를 들어 윈도우 워크로드는 일반적으로 ETW(Event Tracing for Windows)에 로그인하거나
|
||||
애플리케이션 이벤트 로그에 항목을 푸시하도록 구성한다.
|
||||
Microsoft의 오픈 소스 도구인 [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)는
|
||||
|
|
@ -131,8 +131,8 @@ Microsoft의 오픈 소스 도구인 [LogMonitor](https://github.com/microsoft/w
|
|||
LogMonitor는 이벤트 로그, ETW 공급자 그리고 사용자 정의 애플리케이션 로그 모니터링을 지원하고
|
||||
`kubectl logs <pod>` 에 의한 사용을 위해 STDOUT으로 파이프한다.
|
||||
|
||||
LogMonitor Github 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고,
|
||||
LogMonitor에 필요한 입력 지점을 추가해서 로그를 STDOUT으로 푸시한다.
|
||||
LogMonitor GitHub 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고,
|
||||
LogMonitor가 로그를 STDOUT으로 푸시할 수 있도록 필요한 엔트리포인트를 추가한다.
|
||||
|
||||
## 설정 가능한 컨테이너 username 사용하기
|
||||
|
||||
|
|
@ -151,14 +151,14 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
|
|||
|
||||
## 테인트(Taint)와 톨러레이션(Toleration)
|
||||
|
||||
오늘날 사용자는 리눅스와 윈도우 워크로드를 특정 OS 노드별로 보존하기 위해 테인트와
|
||||
노드 셀렉터(nodeSelector)의 조합을 이용해야 한다.
|
||||
오늘날 사용자는 리눅스와 윈도우 워크로드를 (동일한 OS를 실행하는) 적절한 노드에 할당되도록 하기 위해 테인트와
|
||||
노드셀렉터(nodeSelector)의 조합을 이용해야 한다.
|
||||
이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데,
|
||||
이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다.
|
||||
|
||||
### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기
|
||||
|
||||
사용자는 윈도우 컨테이너가 테인트와 톨러레이션을 이용해서 적절한 호스트에서 스케줄링되기를 보장할 수 있다.
|
||||
사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다.
|
||||
오늘날 모든 쿠버네티스 노드는 다음 기본 레이블을 가지고 있다.
|
||||
|
||||
* kubernetes.io/os = [windows|linux]
|
||||
|
|
@ -194,14 +194,14 @@ tolerations:
|
|||
|
||||
### 동일 클러스터에서 여러 윈도우 버전을 조작하는 방법
|
||||
|
||||
파드에서 사용하는 윈도우 서버 버전은 노드 버전과 일치해야 한다. 만약 동일한 클러스터에서 여러 윈도우
|
||||
서버 버전을 사용하려면, 추가로 노드 레이블과 nodeSelectors를 설정해야만 한다.
|
||||
파드에서 사용하는 윈도우 서버 버전은 노드의 윈도우 서버 버전과 일치해야 한다. 만약 동일한 클러스터에서 여러 윈도우
|
||||
서버 버전을 사용하려면, 추가로 노드 레이블과 nodeSelectors를 설정해야 한다.
|
||||
|
||||
쿠버네티스 1.17은 이것을 단순화하기 위해 새로운 레이블인 `node.kubernetes.io/windows-build` 를 자동으로 추가 한다.
|
||||
쿠버네티스 1.17은 이것을 단순화하기 위해 새로운 레이블인 `node.kubernetes.io/windows-build` 를 자동으로 추가한다.
|
||||
만약 이전 버전을 실행 중인 경우, 이 레이블을 윈도우 노드에 수동으로 추가하는 것을 권장한다.
|
||||
|
||||
이 레이블은 호환성을 일치해야 하는 윈도우 메이저, 마이너 및 빌드 번호를 나타낸다.
|
||||
여기에 현재 사용하는 각 윈도우 서버 버전이 있다.
|
||||
이 레이블은 호환성을 위해 일치시켜야 하는 윈도우 메이저, 마이너 및 빌드 번호를 나타낸다.
|
||||
각 윈도우 서버 버전에 대해 현재 사용하고 있는 빌드 번호는 다음과 같다.
|
||||
|
||||
| 제품 이름 | 빌드 번호 |
|
||||
|--------------------------------------|------------------------|
|
||||
|
|
@ -212,12 +212,12 @@ tolerations:
|
|||
|
||||
### RuntimeClass로 단순화
|
||||
|
||||
[RuntimeClass]를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다.
|
||||
클러스터 관리자는 이 테인트와 톨러레이션을 캡슐화하는데 사용되는 `RuntimeClass` 오브젝트를 생성할 수 있다.
|
||||
[런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다.
|
||||
클러스터 관리자는 이 테인트와 톨러레이션을 캡슐화하는 데 사용되는 `RuntimeClass` 오브젝트를 생성할 수 있다.
|
||||
|
||||
|
||||
1. 이 파일을 `runtimeClasses.yml` 로 저장한다. 여기에는 윈도우 OS,
|
||||
아키텍처 및 버전에 적합한 `nodeSelector` 가 포함되었다.
|
||||
아키텍처 및 버전에 적합한 `nodeSelector` 가 포함되어 있다.
|
||||
|
||||
```yaml
|
||||
apiVersion: node.k8s.io/v1
|
||||
|
|
|
|||
Loading…
Reference in New Issue