Skip to content

Commit 56e300c

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #40938 from Virusuki/dev-1.26-ko.1-outdated
[ko] Update outdated files in dev-1.26.-ko.1 [M149-155]
2 parents d657087 + 5cc285f commit 56e300c

File tree

7 files changed

+161
-287
lines changed

7 files changed

+161
-287
lines changed

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

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -89,4 +89,14 @@ content_type: task
8989
kubectl convert -f pod.yaml --output-version v1
9090
```
9191

92-
`kubectl` 도구는 `pod.yaml`의 내용을 `kind`를 파드(변경되지 않음, unchanged)로 설정하는 매니페스트로 대체하고, 수정된 `apiVersion`으로 대체한다.
92+
`kubectl` 도구는 `pod.yaml`의 내용을 `kind`를 파드(변경되지 않음, unchanged)로 설정하는 매니페스트로 대체하고,
93+
수정된 `apiVersion`으로 대체한다.
94+
95+
### 장치 플러그인
96+
97+
클러스터가 장치 플러그인을 실행 중이고 노드를 최신 장치 플러그인 API 버전이 있는
98+
쿠버네티스 릴리스로 업그레이드해야 하는 경우,
99+
업그레이드 중에 장치 할당이 계속 성공적으로 완료되도록 하려면
100+
장치 플러그인을 업그레이드해야 한다.
101+
102+
[API 호환성](docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md/#api-compatibility) 및 [Kubelet 장치 매니저 API 버전](docs/reference/node/device-plugin-api-versions.md)을 참조한다.

‎content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md

Lines changed: 58 additions & 111 deletions
Original file line numberDiff line numberDiff line change
@@ -17,8 +17,6 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한
1717
{{< include "task-tutorial-prereqs.md" >}}
1818

1919
클러스터는 CoreDNS 애드온을 구동하고 있어야 한다.
20-
[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기)
21-
는 `kubeadm` 을 이용하여 `kube-dns` 로부터 이관하는 방법을 설명한다.
2220

2321
{{% version-check %}}
2422

@@ -27,25 +25,27 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한
2725
## 소개
2826

2927
DNS는 _애드온 관리자_ 인 [클러스터 애드온](https://releases.k8s.io/master/cluster/addons/README.md)을
30-
사용하여 자동으로 시작되는 쿠버네티스
31-
내장 서비스이다.
32-
33-
쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우,
34-
CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다.
28+
사용하여 자동으로 시작되는 쿠버네티스 내장 서비스이다.
3529

3630
{{< note >}}
3731
CoreDNS 서비스는 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다.
38-
이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다.
32+
그 의도는 기존의 `kube-dns` 서비스 이름을 사용하여
33+
클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다.
34+
`kube-dns` 로 서비스 이름을 사용하면,
35+
해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다.
3936
{{< /note >}}
4037

41-
CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다.
42-
Kubelet 은 `--cluster-dns=<dns-service-ip>` 플래그를 사용하여 DNS 확인자 정보를 각 컨테이너에 전달한다.
38+
CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우,
39+
일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다.
40+
Kubelet 은 `--cluster-dns=<dns-service-ip>` 플래그를 사용하여
41+
DNS 확인자 정보를 각 컨테이너에 전달한다.
4342

4443
DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=<default-local-domain>` 플래그를
4544
통하여 로컬 도메인을 설정할 수 있다.
4645

47-
DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드), 역방향 IP 주소 조회(PTR 레코드) 등을 지원한다.
48-
더 자세한 내용은 [서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다.
46+
DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드),
47+
역방향 IP 주소 조회(PTR 레코드) 등을 지원한다. 더 자세한 내용은
48+
[서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다.
4949

5050
만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우,
5151
파드는 자신이 실행되는 노드의 이름 변환(name resolution) 구성을 상속한다.
@@ -59,15 +59,16 @@ DNS 상속을 위해 `/etc/resolv.conf` 이외의 파일을 지정할 경우 유
5959

6060
## CoreDNS
6161

62-
CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/specification.md)를 준수하며 클러스터 DNS 역할을 할 수 있는, 범용적인 권한을 갖는 DNS 서버이다.
62+
CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/specification.md)를 준수하며
63+
클러스터 DNS 역할을 할 수 있는, 범용적인 권한을 갖는 DNS 서버이다.
6364

6465
### CoreDNS 컨피그맵(ConfigMap) 옵션
6566

6667
CoreDNS는 모듈형이자 플러그인이 가능한 DNS 서버이며, 각 플러그인들은 CoreDNS에 새로운 기능을 부가한다.
67-
이는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을 관리하여 구성할 수 있다.
68-
클러스터 관리자는 CoreDNS Corefile에 대한 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여
69-
해당 클러스터에 대한 DNS 서비스 검색 동작을
70-
변경할 수 있다.
68+
CoreDNS 서버는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을
69+
관리하여 구성할 수 있다. 클러스터 관리자는 CoreDNS Corefile에 대한
70+
{{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여
71+
해당 클러스터에 대한 DNS 서비스 검색 동작을 변경할 수 있다.
7172

7273
쿠버네티스에서 CoreDNS는 아래의 기본 Corefile 구성으로 설치된다.
7374

@@ -102,35 +103,57 @@ data:
102103
Corefile의 구성은 CoreDNS의 아래 [플러그인](https://coredns.io/plugins)을 포함한다.
103104
104105
* [errors](https://coredns.io/plugins/errors/): 오류가 표준 출력(stdout)에 기록된다.
105-
* [health](https://coredns.io/plugins/health/): CoreDNS의 상태(healthy)가 `http://localhost:8080/health` 에 기록된다. 이 확장 구문에서 `lameduck` 은 프로세스를 비정상 상태(unhealthy)로 만들고, 프로세스가 종료되기 전에 5초 동안 기다린다.
106-
* [ready](https://coredns.io/plugins/ready/): 8181 포트의 HTTP 엔드포인트가, 모든 플러그인이 준비되었다는 신호를 보내면 200 OK 를 반환한다.
107-
* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS가 쿠버네티스의 서비스 및 파드의 IP를 기반으로 DNS 쿼리에 대해 응답한다. 해당 플러그인에 대한 [세부 사항](https://coredns.io/plugins/kubernetes/)은 CoreDNS 웹사이트에서 확인할 수 있다. `ttl` 을 사용하면 응답에 대한 사용자 정의 TTL 을 지정할 수 있으며, 기본값은 5초이다. 허용되는 최소 TTL은 0초이며, 최대값은 3600초이다. 레코드가 캐싱되지 않도록 할 경우, TTL을 0으로 설정한다.
108-
`pods insecure` 옵션은 _kube-dns_ 와의 하위 호환성을 위해 제공된다. `pods verified` 옵션을 사용하여, 일치하는 IP의 동일 네임스페이스(Namespace)에 파드가 존재하는 경우에만 A 레코드를 반환하게 할 수 있다. `pods disabled` 옵션은 파드 레코드를 사용하지 않을 경우 사용된다.
109-
* [prometheus](https://coredns.io/plugins/metrics/): CoreDNS의 메트릭은 [프로메테우스](https://prometheus.io/) 형식(OpenMetrics 라고도 알려진)의 `http://localhost:9153/metrics` 에서 사용 가능하다.
110-
* [forward](https://coredns.io/plugins/forward/): 쿠버네티스 클러스터 도메인에 없는 쿼리들은 모두 사전에 정의된 리졸버(/etc/resolv.conf)로 전달된다.
106+
* [health](https://coredns.io/plugins/health/): CoreDNS의 상태(healthy)가
107+
`http://localhost:8080/health` 에 기록된다. 이 확장 구문에서 `lameduck` 은 프로세스를
108+
비정상 상태(unhealthy)로 만들고, 프로세스가 종료되기 전에 5초 동안 기다린다.
109+
* [ready](https://coredns.io/plugins/ready/): 8181 포트의 HTTP 엔드포인트가,
110+
모든 플러그인이 준비되었다는 신호를 보내면 200 OK 를 반환한다.
111+
* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS가
112+
쿠버네티스의 서비스 및 파드의 IP를 기반으로 DNS 쿼리에 대해 응답한다.
113+
해당 플러그인에 대한 [세부 사항](https://coredns.io/plugins/kubernetes/)은 CoreDNS 웹사이트에서 확인할 수 있다.
114+
- `ttl` 을 사용하면 응답에 대한 사용자 정의 TTL 을 지정할 수 있으며, 기본값은 5초이다.
115+
허용되는 최소 TTL은 0초이며, 최대값은 3600초이다.
116+
레코드가 캐싱되지 않도록 할 경우, TTL을 0으로 설정한다.
117+
- `pods insecure` 옵션은 _kube-dns_ 와의 하위 호환성을 위해 제공된다.
118+
- `pods verified` 옵션을 사용하여, 일치하는 IP의 동일 네임스페이스(Namespace)에 파드가 존재하는 경우에만
119+
A 레코드를 반환하게 할 수 있다.
120+
- `pods disabled` 옵션은 파드 레코드를 사용하지 않을 경우 사용된다.
121+
* [prometheus](https://coredns.io/plugins/metrics/): CoreDNS의 메트릭은
122+
[프로메테우스](https://prometheus.io/) 형식(OpenMetrics 라고도 알려진)의
123+
`http://localhost:9153/metrics` 에서 사용 가능하다.
124+
* [forward](https://coredns.io/plugins/forward/): 쿠버네티스 클러스터 도메인에 없는 쿼리들은
125+
모두 사전에 정의된 리졸버(/etc/resolv.conf)로 전달된다.
111126
* [cache](https://coredns.io/plugins/cache/): 프론트 엔드 캐시를 활성화한다.
112-
* [loop](https://coredns.io/plugins/loop/): 간단한 전달 루프(loop)를 감지하고, 루프가 발견되면 CoreDNS 프로세스를 중단(halt)한다.
113-
* [reload](https://coredns.io/plugins/reload): 변경된 Corefile을 자동으로 다시 로드하도록 한다. 컨피그맵 설정을 변경한 후에 변경 사항이 적용되기 위하여 약 2분정도 소요된다.
114-
* [loadbalance](https://coredns.io/plugins/loadbalance): 응답에 대하여 A, AAAA, MX 레코드의 순서를 무작위로 선정하는 라운드-로빈 DNS 로드밸런서이다.
127+
* [loop](https://coredns.io/plugins/loop/): 간단한 전달 루프(loop)를 감지하고,
128+
루프가 발견되면 CoreDNS 프로세스를 중단(halt)한다.
129+
* [reload](https://coredns.io/plugins/reload): 변경된 Corefile을 자동으로 다시 로드하도록 한다.
130+
컨피그맵 설정을 변경한 후에 변경 사항이 적용되기 위하여 약 2분정도 소요된다.
131+
* [loadbalance](https://coredns.io/plugins/loadbalance): 응답에 대하여 A,
132+
AAAA, MX 레코드의 순서를 무작위로 선정하는 라운드-로빈 DNS 로드밸런서이다.
115133

116134
사용자는 컨피그맵을 변경하여 기본 CoreDNS 동작을 변경할 수 있다.
117135

118136
### CoreDNS를 사용하는 스텁 도메인(Stub-domain)과 업스트림 네임서버(nameserver)의 설정
119137

120-
CoreDNS는 [포워드 플러그인](https://coredns.io/plugins/forward/)을 사용하여 스텁 도메인 및 업스트림 네임서버를 구성할 수 있다.
138+
CoreDNS는 [포워드 플러그인](https://coredns.io/plugins/forward/)을 사용하여
139+
스텁 도메인 및 업스트림 네임서버를 구성할 수 있다.
121140

122141
#### 예시
123-
만약 클러스터 운영자가 10.150.0.1 에 위치한 [Consul](https://www.consul.io/) 도메인 서버를 가지고 있고, 모든 Consul 이름의 접미사가 .consul.local 인 경우, CoreDNS에서 이를 구성하기 위해 클러스터 관리자는 CoreDNS 컨피그맵에서 다음 구문을 생성한다.
142+
143+
만약 클러스터 운영자가 10.150.0.1 에 위치한 [Consul](https://www.consul.io/) 도메인 서버를 가지고 있고,
144+
모든 Consul 이름의 접미사가 .consul.local 인 경우, CoreDNS에서 이를 구성하기 위해
145+
클러스터 관리자는 CoreDNS 컨피그맵에서 다음 구문을 생성한다.
124146

125147
```
126148
consul.local:53 {
127-
errors
128-
cache 30
129-
forward . 10.150.0.1
130-
}
149+
errors
150+
cache 30
151+
forward . 10.150.0.1
152+
}
131153
```
132154
133-
모든 비 클러스터의 DNS 조회가 172.16.0.1 의 특정 네임서버를 통과하도록 할 경우, `/etc/resolv.conf` 대신 `forward` 를 네임서버로 지정한다.
155+
모든 비 클러스터의 DNS 조회가 172.16.0.1 의 특정 네임서버를 통과하도록 할 경우,
156+
`/etc/resolv.conf` 대신 `forward` 를 네임서버로 지정한다.
134157
135158
```
136159
forward . 172.16.0.1
@@ -167,88 +190,12 @@ data:
167190
}
168191
```
169192

170-
`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의
171-
자동 변환을 지원한다.
172-
173193
{{< note >}}
174-
kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 허용하지만 CoreDNS에서는 이 기능을 지원하지 않는다.
194+
CoreDNS는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 지원하지 않는다.
175195
변환 과정에서, 모든 FQDN 네임서버는 CoreDNS 설정에서 생략된다.
176196
{{< /note >}}
177197

178-
## kube-dns에 대응되는 CoreDNS 설정
179-
180-
CoreDNS는 kube-dns 이상의 기능을 지원한다.
181-
`StubDomains` 과 `upstreamNameservers` 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 `forward` 플러그인으로 변환된다.
182-
183-
### 예시
184-
185-
kube-dns에 대한 이 컨피그맵 예제는 stubDomains 및 upstreamNameservers를 지정한다.
186-
187-
```yaml
188-
apiVersion: v1
189-
data:
190-
stubDomains: |
191-
{"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]}
192-
upstreamNameservers: |
193-
["8.8.8.8", "8.8.4.4"]
194-
kind: ConfigMap
195-
```
196-
197-
CoreDNS에서는 동등한 설정으로 Corefile을 생성한다.
198-
199-
* stubDomains 에 대응하는 설정:
200-
```yaml
201-
abc.com:53 {
202-
errors
203-
cache 30
204-
forward . 1.2.3.4
205-
}
206-
my.cluster.local:53 {
207-
errors
208-
cache 30
209-
forward . 2.3.4.5
210-
}
211-
```
212-
213-
기본 플러그인으로 구성된 완전한 Corefile.
214-
215-
```
216-
.:53 {
217-
errors
218-
health
219-
kubernetes cluster.local in-addr.arpa ip6.arpa {
220-
pods insecure
221-
fallthrough in-addr.arpa ip6.arpa
222-
}
223-
federation cluster.local {
224-
foo foo.feddomain.com
225-
}
226-
prometheus :9153
227-
forward . 8.8.8.8 8.8.4.4
228-
cache 30
229-
}
230-
abc.com:53 {
231-
errors
232-
cache 30
233-
forward . 1.2.3.4
234-
}
235-
my.cluster.local:53 {
236-
errors
237-
cache 30
238-
forward . 2.3.4.5
239-
}
240-
```
241-
242-
## CoreDNS로의 이관
243-
244-
kube-dns에서 CoreDNS로 이관하기 위하여,
245-
kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보는
246-
[블로그 기사](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)를 참고한다.
247-
248-
또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를
249-
사용하여 이관할 수도 있다.
250-
251-
252198
## {{% heading "whatsnext" %}}
253199

254200
- [DNS 변환 디버깅하기](/docs/tasks/administer-cluster/dns-debugging-resolution/) 읽기
201+

‎content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -208,8 +208,8 @@ sudo kubeadm upgrade apply
208208
- 노드를 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 전환한다.
209209

210210
```shell
211-
# <node-to-drain>을 드레인하려는 노드의 이름으로 바꾼다.
212-
kubectl uncordon <node-to-drain>
211+
# <node-to-uncordon>을 드레인하려는 노드의 이름으로 바꾼다.
212+
kubectl uncordon <node-to-uncordon>
213213
```
214214

215215
## 워커 노드 업그레이드
@@ -289,8 +289,8 @@ sudo kubeadm upgrade apply
289289
- 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 만든다.
290290

291291
```shell
292-
# <node-to-drain>을 노드의 이름으로 바꾼다.
293-
kubectl uncordon <node-to-drain>
292+
# <node-to-uncordon>을 노드의 이름으로 바꾼다.
293+
kubectl uncordon <node-to-uncordon>
294294
```
295295

296296
## 클러스터 상태 확인

‎content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -167,6 +167,14 @@ resources:
167167
memory: 128Mi
168168
```
169169

170+
{{< note >}}
171+
172+
`리밋레인지`는 적용되는 기본 값의 일관성을 검사하지 않는다. 이는 `리밋레인지`에 의해 설정된 _상한_의 기본값이 클라이언트가 API 서버에 제출하는 사양의 컨테이너에 대해 지정된 _요청량_ 값보다 작을 수 있음을 의미한다. 이 경우, 최종 파드는 스케줄링할 수 없다.
173+
자세한 내용은 [리밋 레인지 개요](/docs/concepts/policy/limit-range/#constraints-on-resource-limits-and-requests)를 참조한다.
174+
175+
{{< /note >}}
176+
177+
170178
## 기본 메모리 상한 및 요청량에 대한 동기
171179

172180
네임스페이스에 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}가

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

Lines changed: 24 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -41,45 +41,40 @@ minikube version: v1.5.2
4141
minikube start --network-plugin=cni
4242
```
4343

44-
minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다.
45-
실리움은 클러스터 구성을 자동으로 감지하고
46-
성공적인 설치를 위해 적절한 구성 요소를 설치한다.
44+
minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다. 그러기 위해서,
45+
먼저 다음과 같은 명령을 사용하여 최신 버전의 CLI를 다운로드 한다.
4746

4847
```shell
4948
curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
49+
```
50+
51+
이후 다음과 같은 명령을 사용하여 다운받은 파일을 `/usr/local/bin` 디렉토리에 압축을 푼다.
52+
53+
```shell
5054
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
5155
rm cilium-linux-amd64.tar.gz
52-
cilium install
5356
```
5457

58+
위의 명령을 실행한 후, 이제 다음 명령으로 실리움(Cilium)을 설치할 수 있다.
59+
5560
```shell
56-
🔮 Auto-detected Kubernetes kind: minikube
57-
✨ Running "minikube" validation checks
58-
✅ Detected minikube version "1.20.0"
59-
ℹ️ Cilium version not set, using default version "v1.10.0"
60-
🔮 Auto-detected cluster name: minikube
61-
🔮 Auto-detected IPAM mode: cluster-pool
62-
🔮 Auto-detected datapath mode: tunnel
63-
🔑 Generating CA...
64-
2021/05/27 02:54:44 [INFO] generate received request
65-
2021/05/27 02:54:44 [INFO] received CSR
66-
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
67-
2021/05/27 02:54:44 [INFO] encoded CSR
68-
2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
69-
🔑 Generating certificates for Hubble...
70-
2021/05/27 02:54:44 [INFO] generate received request
71-
2021/05/27 02:54:44 [INFO] received CSR
72-
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
73-
2021/05/27 02:54:44 [INFO] encoded CSR
74-
2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
75-
🚀 Creating Service accounts...
76-
🚀 Creating Cluster roles...
77-
🚀 Creating ConfigMap...
78-
🚀 Creating Agent DaemonSet...
79-
🚀 Creating Operator Deployment...
80-
⌛ Waiting for Cilium to be installed...
61+
cilium install
8162
```
8263

64+
그런 다음 실리움은 자동으로 클러스터를 구성을 감지하고
65+
성공적인 설치를 위해 적절한 구성요소를 만들고 설치한다.
66+
구성요소는 다음과 같다.
67+
68+
- 시크릿 `cilium-ca`의 인증 기관(CA) 및 Hubble (실리움의 관측 가능성 계층)에 대한 인증서.
69+
- 서비스 어카운트.
70+
- 클러스터 롤.
71+
- 컨피그맵.
72+
- 에이전트 데몬셋 및 오퍼레이터 디플로이먼트.
73+
74+
설치 후, `cilium status` 명령으로 실리움 디플로이먼트의 전체 상태를 볼 수 있다.
75+
`status` 명령으로 예상 출력을 참조한다.
76+
[여기](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#validate-the-installation).
77+
8378
시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
8479
L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, HTTP)의 보안 정책을
8580
적용하는 방법을 설명한다.

0 commit comments

Comments
 (0)