[ko] Update outdated files in dev-1.24-ko.1 M99-M114
Jihoon Seo
parent
507491e619
commit
264e47d7f3
|
|
@ -31,7 +31,7 @@ kubectl config view
|
|||
```
|
||||
|
||||
많은 [예제](https://github.com/kubernetes/examples/tree/master/)는 kubectl 사용에 대한 소개를
|
||||
제공한다. 전체 문서는 [kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에 있다.
|
||||
제공한다. 전체 문서는 [kubectl 매뉴얼](/ko/docs/reference/kubectl/)에 있다.
|
||||
|
||||
### REST API에 직접 접근
|
||||
|
||||
|
|
@ -95,8 +95,25 @@ export CLUSTER_NAME="some_server_name"
|
|||
# 클러스터 이름을 참조하는 API 서버를 가리킨다.
|
||||
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
|
||||
|
||||
# 기본 서비스 어카운트용 토큰을 보관할 시크릿을 생성한다.
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: default-token
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: default
|
||||
type: kubernetes.io/service-account-token
|
||||
EOF
|
||||
|
||||
# 토큰 컨트롤러가 해당 시크릿에 토큰을 기록할 때까지 기다린다.
|
||||
while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
|
||||
echo "waiting for token..." >&2
|
||||
sleep 1
|
||||
done
|
||||
|
||||
# 토큰 값을 얻는다
|
||||
TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode)
|
||||
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
|
||||
|
||||
# TOKEN으로 API 탐색
|
||||
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
|
|
@ -119,26 +136,6 @@ curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
|||
}
|
||||
```
|
||||
|
||||
`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` 디렉터리에
|
||||
|
|
@ -153,7 +150,7 @@ http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한
|
|||
|
||||
### 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), [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}
|
||||
|
||||
|
|
|
|||
|
|
@ -7,14 +7,10 @@ content_type: task
|
|||
이 페이지는 쿠버네티스 퍼시트턴트볼륨(PersistentVolume)의 반환 정책을
|
||||
변경하는 방법을 보여준다.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 왜 퍼시스턴트볼륨 반환 정책을 변경하는가?
|
||||
|
|
@ -33,55 +29,58 @@ content_type: task
|
|||
|
||||
1. 사용자의 클러스터에서 퍼시스턴트볼륨을 조회한다.
|
||||
|
||||
```shell
|
||||
kubectl get pv
|
||||
```
|
||||
```shell
|
||||
kubectl get pv
|
||||
```
|
||||
|
||||
결과는 아래와 같다.
|
||||
결과는 아래와 같다.
|
||||
|
||||
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
|
||||
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s
|
||||
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s
|
||||
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s
|
||||
```none
|
||||
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
|
||||
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s
|
||||
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s
|
||||
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s
|
||||
```
|
||||
|
||||
이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록
|
||||
이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록
|
||||
각 볼륨에 바인딩 되어 있는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 이름도 포함한다.
|
||||
|
||||
1. 사용자의 퍼시스턴트볼륨 중 하나를 선택한 후에 반환 정책을 변경한다.
|
||||
|
||||
```shell
|
||||
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
|
||||
```
|
||||
```shell
|
||||
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
|
||||
```
|
||||
|
||||
`<your-pv-name>` 는 사용자가 선택한 퍼시스턴트볼륨의 이름이다.
|
||||
여기서 `<your-pv-name>` 는 사용자가 선택한 퍼시스턴트볼륨의 이름이다.
|
||||
|
||||
{{< note >}}
|
||||
윈도우에서는, 공백이 포함된 모든 JSONPath 템플릿에 _겹_ 따옴표를 사용해야 한다.(bash에 대해 위에서 표시된 홑 따옴표가 아니다.) 따라서 템플릿의 모든 표현식에서 홑 따옴표를 쓰거나, 이스케이프 처리된 겹 따옴표를 써야 한다. 예를 들면 다음과 같다.
|
||||
{{< note >}}
|
||||
윈도우에서는, 공백이 포함된 모든 JSONPath 템플릿에 _겹_ 따옴표를 사용해야 한다.
|
||||
(bash에 대해 위에서 표시된 홑 따옴표가 아니다.)
|
||||
따라서 템플릿의 모든 표현식에서 홑 따옴표를 쓰거나, 이스케이프 처리된 겹 따옴표를 써야 한다. 예를 들면 다음과 같다.
|
||||
|
||||
```cmd
|
||||
kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"
|
||||
```
|
||||
|
||||
{{< /note >}}
|
||||
```cmd
|
||||
kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
1. 선택한 PersistentVolume이 올바른 정책을 갖는지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pv
|
||||
```
|
||||
```shell
|
||||
kubectl get pv
|
||||
```
|
||||
|
||||
결과는 아래와 같다.
|
||||
|
||||
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
|
||||
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 40s
|
||||
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s
|
||||
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s
|
||||
|
||||
위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을
|
||||
갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우,
|
||||
볼륨은 자동으로 삭제 되지 않는다.
|
||||
결과는 아래와 같다.
|
||||
|
||||
```none
|
||||
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
|
||||
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 40s
|
||||
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s
|
||||
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s
|
||||
```
|
||||
|
||||
위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을
|
||||
갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우,
|
||||
볼륨은 자동으로 삭제 되지 않는다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
@ -91,5 +90,7 @@ kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
|
|||
### 레퍼런스 {#reference}
|
||||
|
||||
* {{< api-reference page="config-and-storage-resources/persistent-volume-v1" >}}
|
||||
* Pay attention to the 퍼시스턴트볼륨의 `.spec.persistentVolumeReclaimPolicy` [필드](docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec)에 주의한다.
|
||||
* 퍼시스턴트볼륨의 `.spec.persistentVolumeReclaimPolicy`
|
||||
[필드](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec)에
|
||||
주의한다.
|
||||
* {{< api-reference page="config-and-storage-resources/persistent-volume-claim-v1" >}}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
title: 서비스 디스커버리를 위해 CoreDNS 사용하기
|
||||
min-kubernetes-server-version: v1.9
|
||||
content_type: task
|
||||
|
|
@ -17,11 +19,14 @@ content_type: task
|
|||
|
||||
## CoreDNS 소개
|
||||
|
||||
[CoreDNS](https://coredns.io)는 쿠버네티스 클러스터의 DNS 역할을 수행할 수 있는, 유연하고 확장 가능한 DNS 서버이다.
|
||||
쿠버네티스와 동일하게, CoreDNS 프로젝트도 {{< glossary_tooltip text="CNCF" term_id="cncf" >}}가 관리한다.
|
||||
[CoreDNS](https://coredns.io)는 쿠버네티스 클러스터의 DNS 역할을 수행할 수 있는,
|
||||
유연하고 확장 가능한 DNS 서버이다.
|
||||
쿠버네티스와 동일하게, CoreDNS 프로젝트도
|
||||
{{< glossary_tooltip text="CNCF" term_id="cncf" >}}가 관리한다.
|
||||
|
||||
사용자는 기존 디플로이먼트인 kube-dns를 교체하거나, 클러스터를 배포하고 업그레이드하는
|
||||
kubeadm과 같은 툴을 사용하여 클러스터 안의 kube-dns 대신 CoreDNS를 사용할 수 있다.
|
||||
사용자는 기존 디플로이먼트인 kube-dns를 교체하거나,
|
||||
클러스터를 배포하고 업그레이드하는 kubeadm과 같은 툴을 사용하여
|
||||
클러스터 안의 kube-dns 대신 CoreDNS를 사용할 수 있다.
|
||||
|
||||
## CoreDNS 설치
|
||||
|
||||
|
|
@ -32,46 +37,43 @@ Kube-dns의 배포나 교체에 관한 매뉴얼은 [CoreDNS GitHub 프로젝트
|
|||
|
||||
### Kubeadm을 사용해 기존 클러스터 업그레이드하기
|
||||
|
||||
쿠버네티스 버전 1.10 이상에서, `kube-dns` 를 사용하는 클러스터를 업그레이드하기 위하여
|
||||
`kubeadm` 을 사용할 때 CoreDNS로 전환할 수도 있다. 이 경우, `kubeadm` 은
|
||||
`kube-dns` 컨피그맵(ConfigMap)을 기반으로 스텁 도메인(stub domain), 업스트림 네임 서버의
|
||||
설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다.
|
||||
쿠버네티스 버전 1.21에서, kubeadm은 DNS 애플리케이션으로서의 `kube-dns` 지원을 제거했다.
|
||||
`kubeadm` v{{< skew currentVersion >}} 버전에서는,
|
||||
DNS 애플리케이션으로 CoreDNS만이 지원된다.
|
||||
|
||||
만약 kube-dns에서 CoreDNS로 이동하는 경우, 업그레이드 과정에서 기능 게이트의 `CoreDNS` 값을 `true` 로 설정해야 한다.
|
||||
예를 들어, `v1.11.0` 로 업그레이드 하는 경우는 다음과 같다.
|
||||
```
|
||||
kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
|
||||
```
|
||||
|
||||
쿠버네티스 1.13 이상에서 기능 게이트의 `CoreDNS` 항목은 제거되었으며, CoreDNS가 기본적으로 사용된다.
|
||||
|
||||
1.11 미만 버전일 경우 업그레이드 과정에서 만들어진 파일이 Corefile을 **덮어쓴다**.
|
||||
**만약 컨피그맵을 사용자 정의한 경우, 기존의 컨피그맵을 저장해야 한다.** 새 컨피그맵이
|
||||
시작된 후에 변경 사항을 다시 적용해야 할 수도 있다.
|
||||
|
||||
만약 쿠버네티스 1.11 이상 버전에서 CoreDNS를 사용하는 경우, 업그레이드 과정에서,
|
||||
기존의 Corefile이 유지된다.
|
||||
|
||||
쿠버네티스 버전 1.21에서, kubeadm 의 `kube-dns` 지원 기능이 삭제되었다.
|
||||
`kube-dns`를 사용 중인 클러스터를 업그레이드하기 위하여
|
||||
`kubeadm` 을 사용할 때 CoreDNS로 전환할 수 있다.
|
||||
이 경우, `kubeadm` 은 `kube-dns` 컨피그맵(ConfigMap)을 기반으로
|
||||
스텁 도메인(stub domain), 업스트림 네임 서버의 설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다.
|
||||
|
||||
## CoreDNS 업그레이드하기
|
||||
|
||||
CoreDNS는 쿠버네티스 1.9 버전부터 사용할 수 있다.
|
||||
쿠버네티스와 함께 제공되는 CoreDNS의 버전과 CoreDNS의 변경 사항은 [여기](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)에서 확인할 수 있다.
|
||||
[쿠버네티스에서의 CoreDNS 버전](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md) 페이지에서,
|
||||
쿠버네티스 각 버전에 대해 kubeadm이 설치하는
|
||||
CoreDNS의 버전을 확인할 수 있다.
|
||||
|
||||
CoreDNS만 업그레이드하고 싶거나 커스텀 이미지를 사용하고 싶은 경우,
|
||||
CoreDNS를 수동으로 업그레이드할 수 있다.
|
||||
[가이드라인 및 따라해보기](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)를 참고하여
|
||||
부드러운 업그레이드를 수행할 수 있다.
|
||||
클러스터를 업그레이드할 때
|
||||
기존 CoreDNS 환경 설정("Corefile")을 보존했는지 확인한다.
|
||||
|
||||
`kubeadm` 도구를 사용하여 클러스터를 업그레이드하는 경우,
|
||||
`kubeadm`이 자동으로 기존 CoreDNS 환경 설정을 보존한다.
|
||||
|
||||
CoreDNS는 사용자 정의 이미지를 사용하거나 CoreDNS만 업그레이드 하려는 경우에 수동으로 업그레이드할 수 있다.
|
||||
업그레이드를 원활하게 수행하는 데 유용한 [가이드라인 및 연습](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)을 참고하자.
|
||||
|
||||
## CoreDNS 튜닝하기
|
||||
|
||||
리소스 활용이 중요한 경우, CoreDNS 구성을 조정하는 것이 유용할 수 있다.
|
||||
더 자세한 내용은 [CoreDNS 스케일링에 대한 설명서](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)를 확인하자.
|
||||
|
||||
|
||||
리소스 활용이 중요한 경우,
|
||||
CoreDNS 구성을 조정하는 것이 유용할 수 있다.
|
||||
더 자세한 내용은 [CoreDNS 스케일링에 대한 설명서](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)를 확인한다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
`Corefile` 을 수정하여 kube-dns 보다 더 많은 유스케이스를 지원하도록
|
||||
[CoreDNS](https://coredns.io)를 구성할 수 있다.
|
||||
더 자세한 내용은 [CoreDNS 웹사이트](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)을 확인하자.
|
||||
CoreDNS 환경 설정("Corefile")을 수정하여
|
||||
kube-dns보다 더 많은 유스케이스를 지원하도록 [CoreDNS](https://coredns.io)를 구성할 수 있다.
|
||||
더 많은 정보는 CoreDNS의 `kubernetes` 플러그인
|
||||
[문서](https://coredns.io/plugins/kubernetes/)를 참고하거나,
|
||||
CoreDNS 블로그의
|
||||
[쿠버네티스를 위한 커스텀 DNS 엔트리](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)를 확인한다.
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ pod/nginx-701339712-e0qfq 1/1 Running 0 35s
|
|||
사용자는 다른 파드에서 새 `nginx` 서비스에 접근할 수 있어야 한다. `default` 네임스페이스에 있는 다른 파드에서 `nginx` 서비스에 접근하기 위하여, busybox 컨테이너를 생성한다.
|
||||
|
||||
```console
|
||||
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
|
||||
kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh
|
||||
```
|
||||
|
||||
사용자 쉘에서, 다음의 명령을 실행한다.
|
||||
|
|
@ -111,7 +111,7 @@ networkpolicy.networking.k8s.io/access-nginx created
|
|||
올바른 레이블이 없는 파드에서 `nginx` 서비스에 접근하려 할 경우, 요청 타임 아웃이 발생한다.
|
||||
|
||||
```console
|
||||
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
|
||||
kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh
|
||||
```
|
||||
|
||||
사용자 쉘에서, 다음의 명령을 실행한다.
|
||||
|
|
@ -130,7 +130,7 @@ wget: download timed out
|
|||
사용자는 요청이 허용되도록 하기 위하여 올바른 레이블을 갖는 파드를 생성한다.
|
||||
|
||||
```console
|
||||
kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh
|
||||
kubectl run busybox --rm -ti --labels="access=true" --image=busybox:1.28 -- /bin/sh
|
||||
```
|
||||
|
||||
사용자 쉘에서, 다음의 명령을 실행한다.
|
||||
|
|
|
|||
|
|
@ -17,8 +17,6 @@ weight: 30
|
|||
쿠버네티스를 사용하여 리눅스와 윈도우 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 윈도우에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 윈도우 노드를 클러스터에 등록하는 방법을 보여준다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
{{< version-check >}}
|
||||
|
||||
|
|
@ -147,33 +145,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
|
|||
{{< /note >}}
|
||||
|
||||
{{< tabs name="tab-windows-kubeadm-runtime-installation" >}}
|
||||
{{% tab name="Docker EE" %}}
|
||||
|
||||
#### Docker EE 설치
|
||||
|
||||
`컨테이너` 기능 설치
|
||||
|
||||
```powershell
|
||||
Install-WindowsFeature -Name containers
|
||||
```
|
||||
|
||||
도커 설치
|
||||
자세한 내용은 [도커 엔진 설치 - 윈도우 서버 엔터프라이즈](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker)에서 확인할 수 있다.
|
||||
|
||||
#### 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 %}}
|
||||
{{% tab name="CRI-containerD" %}}
|
||||
|
||||
#### containerD 설치
|
||||
|
|
@ -191,9 +163,6 @@ curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/lates
|
|||
.\Install-Containerd.ps1 -ContainerDVersion 1.4.1
|
||||
```
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
윈도우 노드에서 이더넷(예: "Ethernet0 2")이 아닌 다른 인터페이스를 사용하는 경우, `-netAdapterName` 으로 이름을 지정한다.
|
||||
|
||||
```powershell
|
||||
|
|
@ -210,17 +179,59 @@ curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools
|
|||
.\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-containerD** 를 사용하는 경우 kubeadm 호출에 `--cri-socket "npipe:////./pipe/containerd-containerd"` 를 추가한다
|
||||
도커 엔진은 컨테이너 런타임이 쿠버네티스와 호환되기 위한 요구 사항인
|
||||
[CRI](/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 >}}
|
||||
|
||||
### 설치 확인
|
||||
|
|
|
|||
|
|
@ -10,7 +10,9 @@ weight: 10
|
|||
|
||||
{{< feature-state for_k8s_version="v1.15" state="stable" >}}
|
||||
|
||||
[kubeadm](/ko/docs/reference/setup-tools/kubeadm/)으로 생성된 클라이언트 인증서는 1년 후에 만료된다. 이 페이지는 kubeadm으로 인증서 갱신을 관리하는 방법을 설명한다.
|
||||
[kubeadm](/ko/docs/reference/setup-tools/kubeadm/)으로 생성된 클라이언트 인증서는 1년 후에 만료된다.
|
||||
이 페이지는 kubeadm으로 인증서 갱신을 관리하는 방법을 설명하며,
|
||||
kubeadm 인증서 관리와 관련된 다른 작업에 대해서도 다룬다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
|
@ -126,7 +128,7 @@ kubeadm 1.17 이전 버전에는 `kubeadm upgrade node` 명령에서
|
|||
|
||||
`kubeadm certs renew` 명령을 사용하여 언제든지 인증서를 수동으로 갱신할 수 있다.
|
||||
|
||||
이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
|
||||
이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
|
||||
|
||||
명령을 실행한 후에는 컨트롤 플레인 파드를 재시작해야 한다.
|
||||
이는 현재 일부 구성 요소 및 인증서에 대해 인증서를 동적으로 다시 로드하는 것이 지원되지 않기 때문이다.
|
||||
|
|
@ -171,7 +173,7 @@ HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서
|
|||
|
||||
빌트인 서명자를 활성화하려면, `--cluster-signing-cert-file` 와 `--cluster-signing-key-file` 플래그를 전달해야 한다.
|
||||
|
||||
새 클러스터를 생성하는 경우, kubeadm [구성 파일](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)을 사용할 수 있다.
|
||||
새 클러스터를 생성하는 경우, kubeadm [구성 파일](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)을 사용할 수 있다.
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
|
|
@ -289,3 +291,52 @@ CSR 서명자를 가지고 있는지 문의하는 것을 추천한다.
|
|||
모두 검증하지 않는 한, 보안이 되는 메커니즘이 아니다. 이것을 통해 악의적 행위자가
|
||||
kubelet 인증서(클라이언트 인증)를 사용하여 아무 IP나 도메인 네임에 대해 인증서를
|
||||
요청하는 CSR의 생성을 방지할 수 있을 것이다.
|
||||
|
||||
## 추가 사용자를 위한 kubeconfig 파일 생성하기 {#kubeconfig-additional-users}
|
||||
|
||||
클러스터 생성 과정에서, kubeadm은
|
||||
`Subject: O = system:masters, CN = kubernetes-admin` 값이 설정되도록 `admin.conf`의 인증서에 서명한다.
|
||||
[`system:masters`](/docs/reference/access-authn-authz/rbac/#user-facing-roles)는
|
||||
인증 계층(예: RBAC)을 우회하는 획기적인 슈퍼유저 그룹이다.
|
||||
`admin.conf`를 추가 사용자와 공유하는 것은 **권장하지 않는다**!
|
||||
|
||||
대신, [`kubeadm kubeconfig user`](/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig)
|
||||
명령어를 사용하여 추가 사용자를 위한 kubeconfig 파일을 생성할 수 있다.
|
||||
이 명령어는 명령줄 플래그와
|
||||
[kubeadm 환경 설정](/docs/reference/config-api/kubeadm-config.v1beta3/) 옵션을 모두 인식한다.
|
||||
생성된 kubeconfig는 stdout으로 출력되며,
|
||||
`kubeadm kubeconfig user ... > somefile.conf` 명령어를 사용하여 파일에 기록될 수 있다.
|
||||
|
||||
다음은 `--config` 플래그와 함께 사용될 수 있는 환경 설정 파일 예시이다.
|
||||
|
||||
```yaml
|
||||
# example.yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: ClusterConfiguration
|
||||
# kubeconfig에서 타겟 "cluster"로 사용될 것이다.
|
||||
clusterName: "kubernetes"
|
||||
# kubeconfig에서 클러스터의 "server"(IP 또는 DNS 이름)로 사용될 것이다.
|
||||
controlPlaneEndpoint: "some-dns-address:6443"
|
||||
# 클러스터 CA 키 및 인증서가 이 로컬 디렉토리에서 로드될 것이다.
|
||||
certificatesDir: "/etc/kubernetes/pki"
|
||||
```
|
||||
|
||||
이러한 항목들이 사용하고자 하는 클러스터의 상세 사항과 일치하는지 확인한다.
|
||||
기존 클러스터의 환경 설정을 보려면 다음 명령을 사용한다.
|
||||
|
||||
```shell
|
||||
kubectl get cm kubeadm-config -n kube-system -o=jsonpath="{.data.ClusterConfiguration}"
|
||||
```
|
||||
|
||||
다음 예시는 `appdevs` 그룹의 새 사용자 `johndoe`를 위해
|
||||
24시간동안 유효한 인증서와 함께 kubeconfig 파일을 생성할 것이다.
|
||||
|
||||
```shell
|
||||
kubeadm kubeconfig user --config example.yaml --org appdevs --client-name johndoe --validity-period 24h
|
||||
```
|
||||
|
||||
다음 예시는 1주일간 유효한 관리자 크리덴셜을 갖는 kubeconfig 파일을 생성할 것이다.
|
||||
|
||||
```shell
|
||||
kubeadm kubeconfig user --config example.yaml --client-name admin --validity-period 168h
|
||||
```
|
||||
|
|
|
|||
|
|
@ -8,10 +8,10 @@ weight: 20
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를
|
||||
{{< skew currentVersionAddMinor -1 >}}.x 버전에서 {{< skew currentVersion >}}.x 버전으로,
|
||||
{{< skew currentVersion >}}.x 버전에서 {{< skew currentVersion >}}.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다. 업그레이드가 지원되지 않는 경우
|
||||
마이너 버전을 건너뛴다.
|
||||
이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를 {{< skew currentVersionAddMinor -1 >}}.x 버전에서 {{< skew currentVersion >}}.x 버전으로,
|
||||
{{< skew currentVersion >}}.x 버전에서 {{< skew currentVersion >}}.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다.
|
||||
업그레이드가 지원되지 않는 경우 마이너 버전을 건너뛴다.
|
||||
더 자세한 정보는 [버전 차이(skew) 정책](/ko/releases/version-skew-policy/)을 참고한다.
|
||||
|
||||
이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면,
|
||||
이 페이지 대신 다음의 페이지들을 참고한다.
|
||||
|
|
@ -43,6 +43,12 @@ weight: 20
|
|||
컨트롤 플레인 노드의 경우, CoreDNS 파드 또는 다른 중요한 워크로드를 실행 중일 수 있다.
|
||||
더 많은 정보는 [노드 드레인하기](/docs/tasks/administer-cluster/safely-drain-node/)를 참조한다.
|
||||
- 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다.
|
||||
- kubelet이 업그레이드된 이후 kubelet 서비스가 성공적으로 재시작되었는지 확인하려면,
|
||||
`systemctl status kubelet` 명령을 실행하거나, `journalctl -xeu kubelet` 명령을 실행하여 서비스 로그를 확인할 수 있다.
|
||||
- 클러스터를 재구성하기 위해 `kubeadm upgrade` 시에
|
||||
[kubeadm 구성 API 종류](/docs/reference/config-api/kubeadm-config.v1beta3)를 명시하여
|
||||
`--config` 플래그를 사용하는 것은 추천하지 않으며 예상치 못한 결과를 초래할 수 있다.
|
||||
대신 [kubeadm 클러스터 재구성하기](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure)를 참조한다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.ya
|
|||
|
||||
결과를 보면 파드가 생성되지 않은 것을 확인할 수 있으며, 이는 해당 파드가 수용 불가능한 컨테이너를 정의하고 있기 때문이다.
|
||||
해당 컨테이너가 수용 불가능한 이유는
|
||||
지정된 최저 CPU 상한보다도 낮은 CPU 상한을 지정하고 있기 때문이다.
|
||||
지정된 최저 CPU 요청량보다도 낮은 CPU 요청량을 지정하고 있기 때문이다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-3.yaml":
|
||||
|
|
|
|||
|
|
@ -130,6 +130,12 @@ kubectl get secret db-user-pass -o jsonpath='{.data}'
|
|||
이제 `password` 데이터를 디코딩할 수 있다.
|
||||
|
||||
```shell
|
||||
# 이 예시는 문서화를 위한 것이다.
|
||||
# 아래와 같은 방법으로 이를 수행했다면,
|
||||
# 'MWYyZDFlMmU2N2Rm' 데이터가 셸 히스토리에 저장될 수 있다.
|
||||
# 당신의 컴퓨터에 접근할 수 있는 사람이 당신 몰래 저장된 명령을 찾아
|
||||
# 시크릿을 base-64 디코드할 수도 있다.
|
||||
# 따라서 이 페이지의 아래 부분에 나오는 다른 단계들과 조합하는 것이 좋다.
|
||||
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
|
||||
```
|
||||
|
||||
|
|
@ -139,6 +145,15 @@ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
|
|||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
인코딩된 시크릿 값이 셸 히스토리에 저장되는 것을 피하려면,
|
||||
다음의 명령을 실행할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get secret db-user-pass -o jsonpath='{.data.password}' | base64 --decode
|
||||
```
|
||||
|
||||
출력은 위의 경우와 유사할 것이다.
|
||||
|
||||
## 삭제
|
||||
|
||||
생성한 시크릿을 삭제하려면 다음 명령을 실행한다.
|
||||
|
|
|
|||
|
|
@ -99,10 +99,10 @@ kubectl get pod memory-demo --output=yaml --namespace=mem-example
|
|||
```yaml
|
||||
...
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
memory: 100Mi
|
||||
limits:
|
||||
memory: 200Mi
|
||||
...
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -225,7 +225,7 @@ kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
|
|||
|
||||
`nltest.exe /parentdomain` 는 다음과 같은 오류를 발생시킨다.
|
||||
|
||||
```
|
||||
```output
|
||||
Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
|
||||
```
|
||||
|
||||
|
|
@ -244,7 +244,8 @@ nltest.exe /query
|
|||
```
|
||||
|
||||
결과는 다음과 같다.
|
||||
```
|
||||
|
||||
```output
|
||||
I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
|
||||
```
|
||||
|
||||
|
|
@ -255,7 +256,8 @@ nltest /sc_reset:domain.example
|
|||
```
|
||||
|
||||
명령이 성공하면 다음과 유사한 출력이 표시된다.
|
||||
```
|
||||
|
||||
```output
|
||||
Flags: 30 HAS_IP HAS_TIMESERV
|
||||
Trusted DC Name \\dc10.domain.example
|
||||
Trusted DC Connection Status Status = 0 0x0 NERR_Success
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ kubectl delete pod qos-demo --namespace=qos-example
|
|||
다음의 경우 파드에 Burstable QoS 클래스가 부여된다.
|
||||
|
||||
* 파드가 Guaranteed QoS 클래스 기준을 만족하지 않는다.
|
||||
* 파드 내에서 최소한 하나의 컨테이너가 메모리 또는 CPU 요청량을 가진다.
|
||||
* 파드 내에서 최소한 하나의 컨테이너가 메모리 또는 CPU 요청량/상한을 가진다.
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
200MiB의 메모리 상한과 100MiB의 메모리 요청량을 가진다.
|
||||
|
|
|
|||
|
|
@ -182,8 +182,7 @@ static-web 1/1 Running 0 2m
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다.
|
||||
[파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/) 에 대해 보기.
|
||||
Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다. [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 및 [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/)를 확인한다.
|
||||
{{< /note >}}
|
||||
|
||||
스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은
|
||||
|
|
|
|||
Loading…
Reference in New Issue