Skip to content

Commit 264e47d

Browse files
jihoon-seojihoon-seo
committed
[ko] Update outdated files in dev-1.24-ko.1 M99-M114
1 parent 507491e commit 264e47d

File tree

13 files changed

+231
-147
lines changed

13 files changed

+231
-147
lines changed

‎content/ko/docs/tasks/administer-cluster/access-cluster-api.md

Lines changed: 20 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -31,7 +31,7 @@ kubectl config view
3131
```
3232

3333
많은 [예제](https://github.com/kubernetes/examples/tree/master/)는 kubectl 사용에 대한 소개를
34-
제공한다. 전체 문서는 [kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에 있다.
34+
제공한다. 전체 문서는 [kubectl 매뉴얼](/ko/docs/reference/kubectl/)에 있다.
3535

3636
### REST API에 직접 접근
3737

@@ -95,8 +95,25 @@ export CLUSTER_NAME="some_server_name"
9595
# 클러스터 이름을 참조하는 API 서버를 가리킨다.
9696
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
9797

98+
# 기본 서비스 어카운트용 토큰을 보관할 시크릿을 생성한다.
99+
kubectl apply -f - <<EOF
100+
apiVersion: v1
101+
kind: Secret
102+
metadata:
103+
name: default-token
104+
annotations:
105+
kubernetes.io/service-account.name: default
106+
type: kubernetes.io/service-account-token
107+
EOF
108+
109+
# 토큰 컨트롤러가 해당 시크릿에 토큰을 기록할 때까지 기다린다.
110+
while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
111+
echo "waiting for token..." >&2
112+
sleep 1
113+
done
114+
98115
# 토큰 값을 얻는다
99-
TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode)
116+
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
100117

101118
# TOKEN으로 API 탐색
102119
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
@@ -119,26 +136,6 @@ curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
119136
}
120137
```
121138

122-
`jsonpath` 방식을 사용한다.
123-
124-
```shell
125-
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
126-
TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
127-
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
128-
{
129-
"kind": "APIVersions",
130-
"versions": [
131-
"v1"
132-
],
133-
"serverAddressByClientCIDRs": [
134-
{
135-
"clientCIDR": "0.0.0.0/0",
136-
"serverAddress": "10.0.1.149:443"
137-
}
138-
]
139-
}
140-
```
141-
142139
위의 예는 `--insecure` 플래그를 사용한다. 이로 인해 MITM 공격이
143140
발생할 수 있다. kubectl이 클러스터에 접근하면 저장된 루트 인증서와
144141
클라이언트 인증서를 사용하여 서버에 접근한다. (`~/.kube` 디렉터리에
@@ -153,7 +150,7 @@ http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한
153150

154151
### API에 프로그래밍 방식으로 접근
155152

156-
쿠버네티스는 공식적으로 [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/)를 참고한다.
153+
쿠버네티스는 공식적으로 [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/)를 참고한다.
157154

158155
#### Go 클라이언트 {#go-client}
159156

‎content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md

Lines changed: 39 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -7,14 +7,10 @@ content_type: task
77
이 페이지는 쿠버네티스 퍼시트턴트볼륨(PersistentVolume)의 반환 정책을
88
변경하는 방법을 보여준다.
99

10-
1110
## {{% heading "prerequisites" %}}
1211

13-
1412
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
1513

16-
17-
1814
<!-- steps -->
1915

2016
## 왜 퍼시스턴트볼륨 반환 정책을 변경하는가?
@@ -33,55 +29,58 @@ content_type: task
3329

3430
1. 사용자의 클러스터에서 퍼시스턴트볼륨을 조회한다.
3531

36-
```shell
37-
kubectl get pv
38-
```
32+
```shell
33+
kubectl get pv
34+
```
3935

40-
결과는 아래와 같다.
36+
결과는 아래와 같다.
4137

42-
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
43-
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s
44-
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s
45-
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s
38+
```none
39+
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
40+
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s
41+
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s
42+
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s
43+
```
4644

47-
이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록
45+
이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록
4846
각 볼륨에 바인딩 되어 있는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 이름도 포함한다.
4947

5048
1. 사용자의 퍼시스턴트볼륨 중 하나를 선택한 후에 반환 정책을 변경한다.
5149

52-
```shell
53-
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
54-
```
50+
```shell
51+
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
52+
```
5553

56-
`<your-pv-name>` 는 사용자가 선택한 퍼시스턴트볼륨의 이름이다.
54+
여기서 `<your-pv-name>` 는 사용자가 선택한 퍼시스턴트볼륨의 이름이다.
5755

58-
{{< note >}}
59-
윈도우에서는, 공백이 포함된 모든 JSONPath 템플릿에 _겹_ 따옴표를 사용해야 한다.(bash에 대해 위에서 표시된 홑 따옴표가 아니다.) 따라서 템플릿의 모든 표현식에서 홑 따옴표를 쓰거나, 이스케이프 처리된 겹 따옴표를 써야 한다. 예를 들면 다음과 같다.
56+
{{< note >}}
57+
윈도우에서는, 공백이 포함된 모든 JSONPath 템플릿에 _겹_ 따옴표를 사용해야 한다.
58+
(bash에 대해 위에서 표시된 홑 따옴표가 아니다.)
59+
따라서 템플릿의 모든 표현식에서 홑 따옴표를 쓰거나, 이스케이프 처리된 겹 따옴표를 써야 한다. 예를 들면 다음과 같다.
6060

61-
```cmd
62-
kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"
63-
```
64-
65-
{{< /note >}}
61+
```cmd
62+
kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"
63+
```
64+
{{< /note >}}
6665

6766
1. 선택한 PersistentVolume이 올바른 정책을 갖는지 확인한다.
6867

69-
```shell
70-
kubectl get pv
71-
```
72-
73-
결과는 아래와 같다.
74-
75-
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
76-
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 40s
77-
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s
78-
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s
68+
```shell
69+
kubectl get pv
70+
```
7971

80-
위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을
81-
갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우,
82-
볼륨은 자동으로 삭제 되지 않는다.
72+
결과는 아래와 같다.
8373

74+
```none
75+
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
76+
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 40s
77+
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s
78+
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s
79+
```
8480

81+
위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을
82+
갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우,
83+
볼륨은 자동으로 삭제 되지 않는다.
8584

8685
## {{% heading "whatsnext" %}}
8786

@@ -91,5 +90,7 @@ kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
9190
### 레퍼런스 {#reference}
9291

9392
* {{< api-reference page="config-and-storage-resources/persistent-volume-v1" >}}
94-
* Pay attention to the 퍼시스턴트볼륨의 `.spec.persistentVolumeReclaimPolicy` [필드](docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec)에 주의한다.
93+
* 퍼시스턴트볼륨의 `.spec.persistentVolumeReclaimPolicy`
94+
[필드](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec)에
95+
주의한다.
9596
* {{< api-reference page="config-and-storage-resources/persistent-volume-claim-v1" >}}

‎content/ko/docs/tasks/administer-cluster/coredns.md

Lines changed: 37 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,6 @@
11
---
2+
3+
24
title: 서비스 디스커버리를 위해 CoreDNS 사용하기
35
min-kubernetes-server-version: v1.9
46
content_type: task
@@ -17,11 +19,14 @@ content_type: task
1719

1820
## CoreDNS 소개
1921

20-
[CoreDNS](https://coredns.io)는 쿠버네티스 클러스터의 DNS 역할을 수행할 수 있는, 유연하고 확장 가능한 DNS 서버이다.
21-
쿠버네티스와 동일하게, CoreDNS 프로젝트도 {{< glossary_tooltip text="CNCF" term_id="cncf" >}}가 관리한다.
22+
[CoreDNS](https://coredns.io)는 쿠버네티스 클러스터의 DNS 역할을 수행할 수 있는,
23+
유연하고 확장 가능한 DNS 서버이다.
24+
쿠버네티스와 동일하게, CoreDNS 프로젝트도
25+
{{< glossary_tooltip text="CNCF" term_id="cncf" >}}가 관리한다.
2226

23-
사용자는 기존 디플로이먼트인 kube-dns를 교체하거나, 클러스터를 배포하고 업그레이드하는
24-
kubeadm과 같은 툴을 사용하여 클러스터 안의 kube-dns 대신 CoreDNS를 사용할 수 있다.
27+
사용자는 기존 디플로이먼트인 kube-dns를 교체하거나,
28+
클러스터를 배포하고 업그레이드하는 kubeadm과 같은 툴을 사용하여
29+
클러스터 안의 kube-dns 대신 CoreDNS를 사용할 수 있다.
2530

2631
## CoreDNS 설치
2732

@@ -32,46 +37,43 @@ Kube-dns의 배포나 교체에 관한 매뉴얼은 [CoreDNS GitHub 프로젝트
3237

3338
### Kubeadm을 사용해 기존 클러스터 업그레이드하기
3439

35-
쿠버네티스 버전 1.10 이상에서, `kube-dns` 를 사용하는 클러스터를 업그레이드하기 위하여
36-
`kubeadm` 을 사용할 때 CoreDNS로 전환할 수도 있다. 이 경우, `kubeadm` 은
37-
`kube-dns` 컨피그맵(ConfigMap)을 기반으로 스텁 도메인(stub domain), 업스트림 네임 서버의
38-
설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다.
39-
40-
만약 kube-dns에서 CoreDNS로 이동하는 경우, 업그레이드 과정에서 기능 게이트의 `CoreDNS` 값을 `true` 로 설정해야 한다.
41-
예를 들어, `v1.11.0` 로 업그레이드 하는 경우는 다음과 같다.
42-
```
43-
kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
44-
```
45-
46-
쿠버네티스 1.13 이상에서 기능 게이트의 `CoreDNS` 항목은 제거되었으며, CoreDNS가 기본적으로 사용된다.
47-
48-
1.11 미만 버전일 경우 업그레이드 과정에서 만들어진 파일이 Corefile을 **덮어쓴다**.
49-
**만약 컨피그맵을 사용자 정의한 경우, 기존의 컨피그맵을 저장해야 한다.** 새 컨피그맵이
50-
시작된 후에 변경 사항을 다시 적용해야 할 수도 있다.
40+
쿠버네티스 버전 1.21에서, kubeadm은 DNS 애플리케이션으로서의 `kube-dns` 지원을 제거했다.
41+
`kubeadm` v{{< skew currentVersion >}} 버전에서는,
42+
DNS 애플리케이션으로 CoreDNS만이 지원된다.
5143

52-
만약 쿠버네티스 1.11 이상 버전에서 CoreDNS를 사용하는 경우, 업그레이드 과정에서,
53-
기존의 Corefile이 유지된다.
54-
55-
쿠버네티스 버전 1.21에서, kubeadm 의 `kube-dns` 지원 기능이 삭제되었다.
44+
`kube-dns`를 사용 중인 클러스터를 업그레이드하기 위하여
45+
`kubeadm` 을 사용할 때 CoreDNS로 전환할 수 있다.
46+
이 경우, `kubeadm` 은 `kube-dns` 컨피그맵(ConfigMap)을 기반으로
47+
스텁 도메인(stub domain), 업스트림 네임 서버의 설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다.
5648

5749
## CoreDNS 업그레이드하기
5850

59-
CoreDNS는 쿠버네티스 1.9 버전부터 사용할 수 있다.
60-
쿠버네티스와 함께 제공되는 CoreDNS의 버전과 CoreDNS의 변경 사항은 [여기](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)에서 확인할 수 있다.
51+
[쿠버네티스에서의 CoreDNS 버전](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md) 페이지에서,
52+
쿠버네티스 각 버전에 대해 kubeadm이 설치하는
53+
CoreDNS의 버전을 확인할 수 있다.
6154

62-
CoreDNS는 사용자 정의 이미지를 사용하거나 CoreDNS만 업그레이드 하려는 경우에 수동으로 업그레이드할 수 있다.
63-
업그레이드를 원활하게 수행하는 데 유용한 [가이드라인 및 연습](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)을 참고하자.
55+
CoreDNS만 업그레이드하고 싶거나 커스텀 이미지를 사용하고 싶은 경우,
56+
CoreDNS를 수동으로 업그레이드할 수 있다.
57+
[가이드라인 및 따라해보기](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)를 참고하여
58+
부드러운 업그레이드를 수행할 수 있다.
59+
클러스터를 업그레이드할 때
60+
기존 CoreDNS 환경 설정("Corefile")을 보존했는지 확인한다.
6461

65-
## CoreDNS 튜닝하기
62+
`kubeadm` 도구를 사용하여 클러스터를 업그레이드하는 경우,
63+
`kubeadm`이 자동으로 기존 CoreDNS 환경 설정을 보존한다.
6664

67-
리소스 활용이 중요한 경우, CoreDNS 구성을 조정하는 것이 유용할 수 있다.
68-
더 자세한 내용은 [CoreDNS 스케일링에 대한 설명서](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)를 확인하자.
6965

66+
## CoreDNS 튜닝하기
7067

68+
리소스 활용이 중요한 경우,
69+
CoreDNS 구성을 조정하는 것이 유용할 수 있다.
70+
더 자세한 내용은 [CoreDNS 스케일링에 대한 설명서](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)를 확인한다.
7171

7272
## {{% heading "whatsnext" %}}
7373

74-
75-
`Corefile` 을 수정하여 kube-dns 보다 더 많은 유스케이스를 지원하도록
76-
[CoreDNS](https://coredns.io)를 구성할 수 있다.
77-
더 자세한 내용은 [CoreDNS 웹사이트](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)을 확인하자.
74+
CoreDNS 환경 설정("Corefile")을 수정하여
75+
kube-dns보다 더 많은 유스케이스를 지원하도록 [CoreDNS](https://coredns.io)를 구성할 수 있다.
76+
더 많은 정보는 CoreDNS의 `kubernetes` 플러그인
77+
[문서](https://coredns.io/plugins/kubernetes/)를 참고하거나,
78+
CoreDNS 블로그의
79+
[쿠버네티스를 위한 커스텀 DNS 엔트리](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)를 확인한다.

‎content/ko/docs/tasks/administer-cluster/declare-network-policy.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -68,7 +68,7 @@ pod/nginx-701339712-e0qfq 1/1 Running 0 35s
6868
사용자는 다른 파드에서 새 `nginx` 서비스에 접근할 수 있어야 한다. `default` 네임스페이스에 있는 다른 파드에서 `nginx` 서비스에 접근하기 위하여, busybox 컨테이너를 생성한다.
6969

7070
```console
71-
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
71+
kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh
7272
```
7373

7474
사용자 쉘에서, 다음의 명령을 실행한다.
@@ -111,7 +111,7 @@ networkpolicy.networking.k8s.io/access-nginx created
111111
올바른 레이블이 없는 파드에서 `nginx` 서비스에 접근하려 할 경우, 요청 타임 아웃이 발생한다.
112112

113113
```console
114-
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
114+
kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh
115115
```
116116

117117
사용자 쉘에서, 다음의 명령을 실행한다.
@@ -130,7 +130,7 @@ wget: download timed out
130130
사용자는 요청이 허용되도록 하기 위하여 올바른 레이블을 갖는 파드를 생성한다.
131131

132132
```console
133-
kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh
133+
kubectl run busybox --rm -ti --labels="access=true" --image=busybox:1.28 -- /bin/sh
134134
```
135135

136136
사용자 쉘에서, 다음의 명령을 실행한다.

0 commit comments

Comments
 (0)