[ko] Update outdated files in dev-1.26.-ko.1 [M149-155]
Update outdated files in dev-1.26.-ko.1 [M149-155]pull/40938/head
namuk2004
parent
bfd26ffc0d
commit
5cc285f781
|
|
@ -89,4 +89,14 @@ content_type: task
|
|||
kubectl convert -f pod.yaml --output-version v1
|
||||
```
|
||||
|
||||
`kubectl` 도구는 `pod.yaml`의 내용을 `kind`를 파드(변경되지 않음, unchanged)로 설정하는 매니페스트로 대체하고, 수정된 `apiVersion`으로 대체한다.
|
||||
`kubectl` 도구는 `pod.yaml`의 내용을 `kind`를 파드(변경되지 않음, unchanged)로 설정하는 매니페스트로 대체하고,
|
||||
수정된 `apiVersion`으로 대체한다.
|
||||
|
||||
### 장치 플러그인
|
||||
|
||||
클러스터가 장치 플러그인을 실행 중이고 노드를 최신 장치 플러그인 API 버전이 있는
|
||||
쿠버네티스 릴리스로 업그레이드해야 하는 경우,
|
||||
업그레이드 중에 장치 할당이 계속 성공적으로 완료되도록 하려면
|
||||
장치 플러그인을 업그레이드해야 한다.
|
||||
|
||||
[API 호환성](docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md/#api-compatibility) 및 [Kubelet 장치 매니저 API 버전](docs/reference/node/device-plugin-api-versions.md)을 참조한다.
|
||||
|
|
|
|||
|
|
@ -17,8 +17,6 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한
|
|||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
클러스터는 CoreDNS 애드온을 구동하고 있어야 한다.
|
||||
[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기)
|
||||
는 `kubeadm` 을 이용하여 `kube-dns` 로부터 이관하는 방법을 설명한다.
|
||||
|
||||
{{% version-check %}}
|
||||
|
||||
|
|
@ -27,25 +25,27 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한
|
|||
## 소개
|
||||
|
||||
DNS는 _애드온 관리자_ 인 [클러스터 애드온](https://releases.k8s.io/master/cluster/addons/README.md)을
|
||||
사용하여 자동으로 시작되는 쿠버네티스
|
||||
내장 서비스이다.
|
||||
|
||||
쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우,
|
||||
CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다.
|
||||
사용하여 자동으로 시작되는 쿠버네티스 내장 서비스이다.
|
||||
|
||||
{{< note >}}
|
||||
CoreDNS 서비스는 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다.
|
||||
이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다.
|
||||
그 의도는 기존의 `kube-dns` 서비스 이름을 사용하여
|
||||
클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다.
|
||||
`kube-dns` 로 서비스 이름을 사용하면,
|
||||
해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다.
|
||||
{{< /note >}}
|
||||
|
||||
CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다.
|
||||
Kubelet 은 `--cluster-dns=<dns-service-ip>` 플래그를 사용하여 DNS 확인자 정보를 각 컨테이너에 전달한다.
|
||||
CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우,
|
||||
일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다.
|
||||
Kubelet 은 `--cluster-dns=<dns-service-ip>` 플래그를 사용하여
|
||||
DNS 확인자 정보를 각 컨테이너에 전달한다.
|
||||
|
||||
DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=<default-local-domain>` 플래그를
|
||||
통하여 로컬 도메인을 설정할 수 있다.
|
||||
|
||||
DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드), 역방향 IP 주소 조회(PTR 레코드) 등을 지원한다.
|
||||
더 자세한 내용은 [서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다.
|
||||
DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드),
|
||||
역방향 IP 주소 조회(PTR 레코드) 등을 지원한다. 더 자세한 내용은
|
||||
[서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다.
|
||||
|
||||
만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우,
|
||||
파드는 자신이 실행되는 노드의 이름 변환(name resolution) 구성을 상속한다.
|
||||
|
|
@ -59,15 +59,16 @@ DNS 상속을 위해 `/etc/resolv.conf` 이외의 파일을 지정할 경우 유
|
|||
|
||||
## CoreDNS
|
||||
|
||||
CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/specification.md)를 준수하며 클러스터 DNS 역할을 할 수 있는, 범용적인 권한을 갖는 DNS 서버이다.
|
||||
CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/specification.md)를 준수하며
|
||||
클러스터 DNS 역할을 할 수 있는, 범용적인 권한을 갖는 DNS 서버이다.
|
||||
|
||||
### CoreDNS 컨피그맵(ConfigMap) 옵션
|
||||
|
||||
CoreDNS는 모듈형이자 플러그인이 가능한 DNS 서버이며, 각 플러그인들은 CoreDNS에 새로운 기능을 부가한다.
|
||||
이는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을 관리하여 구성할 수 있다.
|
||||
클러스터 관리자는 CoreDNS Corefile에 대한 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여
|
||||
해당 클러스터에 대한 DNS 서비스 검색 동작을
|
||||
변경할 수 있다.
|
||||
CoreDNS 서버는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을
|
||||
관리하여 구성할 수 있다. 클러스터 관리자는 CoreDNS Corefile에 대한
|
||||
{{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여
|
||||
해당 클러스터에 대한 DNS 서비스 검색 동작을 변경할 수 있다.
|
||||
|
||||
쿠버네티스에서 CoreDNS는 아래의 기본 Corefile 구성으로 설치된다.
|
||||
|
||||
|
|
@ -102,35 +103,57 @@ data:
|
|||
Corefile의 구성은 CoreDNS의 아래 [플러그인](https://coredns.io/plugins)을 포함한다.
|
||||
|
||||
* [errors](https://coredns.io/plugins/errors/): 오류가 표준 출력(stdout)에 기록된다.
|
||||
* [health](https://coredns.io/plugins/health/): CoreDNS의 상태(healthy)가 `http://localhost:8080/health` 에 기록된다. 이 확장 구문에서 `lameduck` 은 프로세스를 비정상 상태(unhealthy)로 만들고, 프로세스가 종료되기 전에 5초 동안 기다린다.
|
||||
* [ready](https://coredns.io/plugins/ready/): 8181 포트의 HTTP 엔드포인트가, 모든 플러그인이 준비되었다는 신호를 보내면 200 OK 를 반환한다.
|
||||
* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS가 쿠버네티스의 서비스 및 파드의 IP를 기반으로 DNS 쿼리에 대해 응답한다. 해당 플러그인에 대한 [세부 사항](https://coredns.io/plugins/kubernetes/)은 CoreDNS 웹사이트에서 확인할 수 있다. `ttl` 을 사용하면 응답에 대한 사용자 정의 TTL 을 지정할 수 있으며, 기본값은 5초이다. 허용되는 최소 TTL은 0초이며, 최대값은 3600초이다. 레코드가 캐싱되지 않도록 할 경우, TTL을 0으로 설정한다.
|
||||
`pods insecure` 옵션은 _kube-dns_ 와의 하위 호환성을 위해 제공된다. `pods verified` 옵션을 사용하여, 일치하는 IP의 동일 네임스페이스(Namespace)에 파드가 존재하는 경우에만 A 레코드를 반환하게 할 수 있다. `pods disabled` 옵션은 파드 레코드를 사용하지 않을 경우 사용된다.
|
||||
* [prometheus](https://coredns.io/plugins/metrics/): CoreDNS의 메트릭은 [프로메테우스](https://prometheus.io/) 형식(OpenMetrics 라고도 알려진)의 `http://localhost:9153/metrics` 에서 사용 가능하다.
|
||||
* [forward](https://coredns.io/plugins/forward/): 쿠버네티스 클러스터 도메인에 없는 쿼리들은 모두 사전에 정의된 리졸버(/etc/resolv.conf)로 전달된다.
|
||||
* [health](https://coredns.io/plugins/health/): CoreDNS의 상태(healthy)가
|
||||
`http://localhost:8080/health` 에 기록된다. 이 확장 구문에서 `lameduck` 은 프로세스를
|
||||
비정상 상태(unhealthy)로 만들고, 프로세스가 종료되기 전에 5초 동안 기다린다.
|
||||
* [ready](https://coredns.io/plugins/ready/): 8181 포트의 HTTP 엔드포인트가,
|
||||
모든 플러그인이 준비되었다는 신호를 보내면 200 OK 를 반환한다.
|
||||
* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS가
|
||||
쿠버네티스의 서비스 및 파드의 IP를 기반으로 DNS 쿼리에 대해 응답한다.
|
||||
해당 플러그인에 대한 [세부 사항](https://coredns.io/plugins/kubernetes/)은 CoreDNS 웹사이트에서 확인할 수 있다.
|
||||
- `ttl` 을 사용하면 응답에 대한 사용자 정의 TTL 을 지정할 수 있으며, 기본값은 5초이다.
|
||||
허용되는 최소 TTL은 0초이며, 최대값은 3600초이다.
|
||||
레코드가 캐싱되지 않도록 할 경우, TTL을 0으로 설정한다.
|
||||
- `pods insecure` 옵션은 _kube-dns_ 와의 하위 호환성을 위해 제공된다.
|
||||
- `pods verified` 옵션을 사용하여, 일치하는 IP의 동일 네임스페이스(Namespace)에 파드가 존재하는 경우에만
|
||||
A 레코드를 반환하게 할 수 있다.
|
||||
- `pods disabled` 옵션은 파드 레코드를 사용하지 않을 경우 사용된다.
|
||||
* [prometheus](https://coredns.io/plugins/metrics/): CoreDNS의 메트릭은
|
||||
[프로메테우스](https://prometheus.io/) 형식(OpenMetrics 라고도 알려진)의
|
||||
`http://localhost:9153/metrics` 에서 사용 가능하다.
|
||||
* [forward](https://coredns.io/plugins/forward/): 쿠버네티스 클러스터 도메인에 없는 쿼리들은
|
||||
모두 사전에 정의된 리졸버(/etc/resolv.conf)로 전달된다.
|
||||
* [cache](https://coredns.io/plugins/cache/): 프론트 엔드 캐시를 활성화한다.
|
||||
* [loop](https://coredns.io/plugins/loop/): 간단한 전달 루프(loop)를 감지하고, 루프가 발견되면 CoreDNS 프로세스를 중단(halt)한다.
|
||||
* [reload](https://coredns.io/plugins/reload): 변경된 Corefile을 자동으로 다시 로드하도록 한다. 컨피그맵 설정을 변경한 후에 변경 사항이 적용되기 위하여 약 2분정도 소요된다.
|
||||
* [loadbalance](https://coredns.io/plugins/loadbalance): 응답에 대하여 A, AAAA, MX 레코드의 순서를 무작위로 선정하는 라운드-로빈 DNS 로드밸런서이다.
|
||||
* [loop](https://coredns.io/plugins/loop/): 간단한 전달 루프(loop)를 감지하고,
|
||||
루프가 발견되면 CoreDNS 프로세스를 중단(halt)한다.
|
||||
* [reload](https://coredns.io/plugins/reload): 변경된 Corefile을 자동으로 다시 로드하도록 한다.
|
||||
컨피그맵 설정을 변경한 후에 변경 사항이 적용되기 위하여 약 2분정도 소요된다.
|
||||
* [loadbalance](https://coredns.io/plugins/loadbalance): 응답에 대하여 A,
|
||||
AAAA, MX 레코드의 순서를 무작위로 선정하는 라운드-로빈 DNS 로드밸런서이다.
|
||||
|
||||
사용자는 컨피그맵을 변경하여 기본 CoreDNS 동작을 변경할 수 있다.
|
||||
|
||||
### CoreDNS를 사용하는 스텁 도메인(Stub-domain)과 업스트림 네임서버(nameserver)의 설정
|
||||
|
||||
CoreDNS는 [포워드 플러그인](https://coredns.io/plugins/forward/)을 사용하여 스텁 도메인 및 업스트림 네임서버를 구성할 수 있다.
|
||||
CoreDNS는 [포워드 플러그인](https://coredns.io/plugins/forward/)을 사용하여
|
||||
스텁 도메인 및 업스트림 네임서버를 구성할 수 있다.
|
||||
|
||||
#### 예시
|
||||
만약 클러스터 운영자가 10.150.0.1 에 위치한 [Consul](https://www.consul.io/) 도메인 서버를 가지고 있고, 모든 Consul 이름의 접미사가 .consul.local 인 경우, CoreDNS에서 이를 구성하기 위해 클러스터 관리자는 CoreDNS 컨피그맵에서 다음 구문을 생성한다.
|
||||
|
||||
만약 클러스터 운영자가 10.150.0.1 에 위치한 [Consul](https://www.consul.io/) 도메인 서버를 가지고 있고,
|
||||
모든 Consul 이름의 접미사가 .consul.local 인 경우, CoreDNS에서 이를 구성하기 위해
|
||||
클러스터 관리자는 CoreDNS 컨피그맵에서 다음 구문을 생성한다.
|
||||
|
||||
```
|
||||
consul.local:53 {
|
||||
errors
|
||||
cache 30
|
||||
forward . 10.150.0.1
|
||||
}
|
||||
errors
|
||||
cache 30
|
||||
forward . 10.150.0.1
|
||||
}
|
||||
```
|
||||
|
||||
모든 비 클러스터의 DNS 조회가 172.16.0.1 의 특정 네임서버를 통과하도록 할 경우, `/etc/resolv.conf` 대신 `forward` 를 네임서버로 지정한다.
|
||||
모든 비 클러스터의 DNS 조회가 172.16.0.1 의 특정 네임서버를 통과하도록 할 경우,
|
||||
`/etc/resolv.conf` 대신 `forward` 를 네임서버로 지정한다.
|
||||
|
||||
```
|
||||
forward . 172.16.0.1
|
||||
|
|
@ -167,88 +190,12 @@ data:
|
|||
}
|
||||
```
|
||||
|
||||
`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의
|
||||
자동 변환을 지원한다.
|
||||
|
||||
{{< note >}}
|
||||
kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 허용하지만 CoreDNS에서는 이 기능을 지원하지 않는다.
|
||||
CoreDNS는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 지원하지 않는다.
|
||||
변환 과정에서, 모든 FQDN 네임서버는 CoreDNS 설정에서 생략된다.
|
||||
{{< /note >}}
|
||||
|
||||
## kube-dns에 대응되는 CoreDNS 설정
|
||||
|
||||
CoreDNS는 kube-dns 이상의 기능을 지원한다.
|
||||
`StubDomains` 과 `upstreamNameservers` 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 `forward` 플러그인으로 변환된다.
|
||||
|
||||
### 예시
|
||||
|
||||
kube-dns에 대한 이 컨피그맵 예제는 stubDomains 및 upstreamNameservers를 지정한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
stubDomains: |
|
||||
{"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]}
|
||||
upstreamNameservers: |
|
||||
["8.8.8.8", "8.8.4.4"]
|
||||
kind: ConfigMap
|
||||
```
|
||||
|
||||
CoreDNS에서는 동등한 설정으로 Corefile을 생성한다.
|
||||
|
||||
* stubDomains 에 대응하는 설정:
|
||||
```yaml
|
||||
abc.com:53 {
|
||||
errors
|
||||
cache 30
|
||||
forward . 1.2.3.4
|
||||
}
|
||||
my.cluster.local:53 {
|
||||
errors
|
||||
cache 30
|
||||
forward . 2.3.4.5
|
||||
}
|
||||
```
|
||||
|
||||
기본 플러그인으로 구성된 완전한 Corefile.
|
||||
|
||||
```
|
||||
.:53 {
|
||||
errors
|
||||
health
|
||||
kubernetes cluster.local in-addr.arpa ip6.arpa {
|
||||
pods insecure
|
||||
fallthrough in-addr.arpa ip6.arpa
|
||||
}
|
||||
federation cluster.local {
|
||||
foo foo.feddomain.com
|
||||
}
|
||||
prometheus :9153
|
||||
forward . 8.8.8.8 8.8.4.4
|
||||
cache 30
|
||||
}
|
||||
abc.com:53 {
|
||||
errors
|
||||
cache 30
|
||||
forward . 1.2.3.4
|
||||
}
|
||||
my.cluster.local:53 {
|
||||
errors
|
||||
cache 30
|
||||
forward . 2.3.4.5
|
||||
}
|
||||
```
|
||||
|
||||
## CoreDNS로의 이관
|
||||
|
||||
kube-dns에서 CoreDNS로 이관하기 위하여,
|
||||
kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보는
|
||||
[블로그 기사](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)를 참고한다.
|
||||
|
||||
또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를
|
||||
사용하여 이관할 수도 있다.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [DNS 변환 디버깅하기](/docs/tasks/administer-cluster/dns-debugging-resolution/) 읽기
|
||||
|
||||
|
|
|
|||
|
|
@ -208,8 +208,8 @@ sudo kubeadm upgrade apply
|
|||
- 노드를 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 전환한다.
|
||||
|
||||
```shell
|
||||
# <node-to-drain>을 드레인하려는 노드의 이름으로 바꾼다.
|
||||
kubectl uncordon <node-to-drain>
|
||||
# <node-to-uncordon>을 드레인하려는 노드의 이름으로 바꾼다.
|
||||
kubectl uncordon <node-to-uncordon>
|
||||
```
|
||||
|
||||
## 워커 노드 업그레이드
|
||||
|
|
@ -289,8 +289,8 @@ sudo kubeadm upgrade apply
|
|||
- 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 만든다.
|
||||
|
||||
```shell
|
||||
# <node-to-drain>을 노드의 이름으로 바꾼다.
|
||||
kubectl uncordon <node-to-drain>
|
||||
# <node-to-uncordon>을 노드의 이름으로 바꾼다.
|
||||
kubectl uncordon <node-to-uncordon>
|
||||
```
|
||||
|
||||
## 클러스터 상태 확인
|
||||
|
|
|
|||
|
|
@ -167,6 +167,14 @@ resources:
|
|||
memory: 128Mi
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
||||
`리밋레인지`는 적용되는 기본 값의 일관성을 검사하지 않는다. 이는 `리밋레인지`에 의해 설정된 _상한_의 기본값이 클라이언트가 API 서버에 제출하는 사양의 컨테이너에 대해 지정된 _요청량_ 값보다 작을 수 있음을 의미한다. 이 경우, 최종 파드는 스케줄링할 수 없다.
|
||||
자세한 내용은 [리밋 레인지 개요](/docs/concepts/policy/limit-range/#constraints-on-resource-limits-and-requests)를 참조한다.
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
## 기본 메모리 상한 및 요청량에 대한 동기
|
||||
|
||||
네임스페이스에 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}가
|
||||
|
|
|
|||
|
|
@ -41,44 +41,39 @@ minikube version: v1.5.2
|
|||
minikube start --network-plugin=cni
|
||||
```
|
||||
|
||||
minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다.
|
||||
실리움은 클러스터 구성을 자동으로 감지하고
|
||||
성공적인 설치를 위해 적절한 구성 요소를 설치한다.
|
||||
minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다. 그러기 위해서,
|
||||
먼저 다음과 같은 명령을 사용하여 최신 버전의 CLI를 다운로드 한다.
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
|
||||
```
|
||||
|
||||
이후 다음과 같은 명령을 사용하여 다운받은 파일을 `/usr/local/bin` 디렉토리에 압축을 푼다.
|
||||
|
||||
```shell
|
||||
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
|
||||
rm cilium-linux-amd64.tar.gz
|
||||
```
|
||||
|
||||
위의 명령을 실행한 후, 이제 다음 명령으로 실리움(Cilium)을 설치할 수 있다.
|
||||
|
||||
```shell
|
||||
cilium install
|
||||
```
|
||||
|
||||
```shell
|
||||
🔮 Auto-detected Kubernetes kind: minikube
|
||||
✨ Running "minikube" validation checks
|
||||
✅ Detected minikube version "1.20.0"
|
||||
ℹ️ Cilium version not set, using default version "v1.10.0"
|
||||
🔮 Auto-detected cluster name: minikube
|
||||
🔮 Auto-detected IPAM mode: cluster-pool
|
||||
🔮 Auto-detected datapath mode: tunnel
|
||||
🔑 Generating CA...
|
||||
2021/05/27 02:54:44 [INFO] generate received request
|
||||
2021/05/27 02:54:44 [INFO] received CSR
|
||||
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
|
||||
2021/05/27 02:54:44 [INFO] encoded CSR
|
||||
2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
|
||||
🔑 Generating certificates for Hubble...
|
||||
2021/05/27 02:54:44 [INFO] generate received request
|
||||
2021/05/27 02:54:44 [INFO] received CSR
|
||||
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
|
||||
2021/05/27 02:54:44 [INFO] encoded CSR
|
||||
2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
|
||||
🚀 Creating Service accounts...
|
||||
🚀 Creating Cluster roles...
|
||||
🚀 Creating ConfigMap...
|
||||
🚀 Creating Agent DaemonSet...
|
||||
🚀 Creating Operator Deployment...
|
||||
⌛ Waiting for Cilium to be installed...
|
||||
```
|
||||
그런 다음 실리움은 자동으로 클러스터를 구성을 감지하고
|
||||
성공적인 설치를 위해 적절한 구성요소를 만들고 설치한다.
|
||||
구성요소는 다음과 같다.
|
||||
|
||||
- 시크릿 `cilium-ca`의 인증 기관(CA) 및 Hubble (실리움의 관측 가능성 계층)에 대한 인증서.
|
||||
- 서비스 어카운트.
|
||||
- 클러스터 롤.
|
||||
- 컨피그맵.
|
||||
- 에이전트 데몬셋 및 오퍼레이터 디플로이먼트.
|
||||
|
||||
설치 후, `cilium status` 명령으로 실리움 디플로이먼트의 전체 상태를 볼 수 있다.
|
||||
`status` 명령으로 예상 출력을 참조한다.
|
||||
[여기](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#validate-the-installation).
|
||||
|
||||
시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
|
||||
L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, HTTP)의 보안 정책을
|
||||
|
|
|
|||
|
|
@ -47,8 +47,7 @@ apiVersion: v1
|
|||
`kubectl` 또는 쿠버네티스 API를 사용해
|
||||
포그라운드 캐스케이딩 삭제로 전환할 수 있다. {{<version-check>}}
|
||||
|
||||
{{<tabs name="foreground_deletion">}}
|
||||
{{% tab name="쿠버네티스 1.20.x 이후 버전" %}}
|
||||
|
||||
`kubectl` 또는 쿠버네티스 API를 사용해
|
||||
포그라운드 캐스케이딩 삭제로 오브젝트들을 삭제할 수 있다.
|
||||
|
||||
|
|
@ -96,47 +95,6 @@ kubectl delete deployment nginx-deployment --cascade=foreground
|
|||
...
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="쿠버네티스 1.20.x 전 버전" %}}
|
||||
쿠버네티스 API를 사용해
|
||||
포그라운드 캐스케이딩 삭제로 오브젝트들을 삭제할 수 있다.
|
||||
|
||||
상세한 내용은 [쿠버네티스 버전에 따른 문서](/ko/docs/home/supported-doc-versions/)를 참고한다.
|
||||
|
||||
1. 로컬 프록시 세션을 시작한다.
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
|
||||
1. 삭제를 작동시키기 위해 `curl`을 사용한다.
|
||||
|
||||
```shell
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
출력에는 다음과 같이
|
||||
`foregroundDeletion` {{<glossary_tooltip text="파이널라이저(finalizer)" term_id="finalizer">}}가 포함되어 있다.
|
||||
|
||||
```
|
||||
"kind": "Deployment",
|
||||
"apiVersion": "apps/v1",
|
||||
"metadata": {
|
||||
"name": "nginx-deployment",
|
||||
"namespace": "default",
|
||||
"uid": "d1ce1b02-cae8-4288-8a53-30e84d8fa505",
|
||||
"resourceVersion": "1363097",
|
||||
"creationTimestamp": "2021-07-08T20:24:37Z",
|
||||
"deletionTimestamp": "2021-07-08T20:27:39Z",
|
||||
"finalizers": [
|
||||
"foregroundDeletion"
|
||||
]
|
||||
...
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{</tabs>}}
|
||||
|
||||
## 백그라운드 캐스케이딩 삭제 사용 {#use-background-cascading-deletion}
|
||||
|
||||
|
|
@ -144,8 +102,6 @@ kubectl delete deployment nginx-deployment --cascade=foreground
|
|||
1. 클러스터를 실행하는 쿠버네티스 버전에 따라
|
||||
디플로이먼트를 삭제하기 위해 `kubectl` 또는 쿠버네티스 API를 사용한다. {{<version-check>}}
|
||||
|
||||
{{<tabs name="background_deletion">}}
|
||||
{{% tab name="쿠버네티스 1.20.x 이후 버전" %}}
|
||||
|
||||
`kubectl` 또는 쿠버네티스 API를 사용해
|
||||
백그라운드 캐스케이딩 삭제로 오브젝트들을 삭제할 수 있다.
|
||||
|
|
@ -192,54 +148,6 @@ kubectl delete deployment nginx-deployment --cascade=background
|
|||
"uid": "cc9eefb9-2d49-4445-b1c1-d261c9396456"
|
||||
}
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="쿠버네티스 1.20.x 전 버전" %}}
|
||||
쿠버네티스는 기본적으로 백그라운드 캐스케이딩 삭제를 사용하므로, `--cascade` 플래그
|
||||
또는 `propagationPolicy: Background` 인수 없이
|
||||
다음 명령을 실행해도 같은 작업을 수행한다.
|
||||
|
||||
상세한 내용은 [쿠버네티스 버전에 따른 문서](/ko/docs/home/supported-doc-versions/)를 참고한다.
|
||||
|
||||
**kubectl 사용**
|
||||
|
||||
다음 명령어를 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl delete deployment nginx-deployment --cascade=true
|
||||
```
|
||||
|
||||
**쿠버네티스 API 사용**
|
||||
|
||||
1. 로컬 프록시 세션을 시작한다.
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
|
||||
1. 삭제를 작동시키기 위해 `curl`을 사용한다.
|
||||
|
||||
```shell
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
출력은 다음과 유사하다.
|
||||
|
||||
```
|
||||
"kind": "Status",
|
||||
"apiVersion": "v1",
|
||||
...
|
||||
"status": "Success",
|
||||
"details": {
|
||||
"name": "nginx-deployment",
|
||||
"group": "apps",
|
||||
"kind": "deployments",
|
||||
"uid": "cc9eefb9-2d49-4445-b1c1-d261c9396456"
|
||||
}
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{</tabs>}}
|
||||
|
||||
|
||||
## 소유자 오브젝트 및 종속된 고아(orphan) 오브젝트 삭제 {#set-orphan-deletion-policy}
|
||||
|
|
@ -250,8 +158,6 @@ kubectl delete deployment nginx-deployment --cascade=true
|
|||
쿠버네티스 버전에 따라 `kubectl` 또는 쿠버네티스 API를 사용해
|
||||
종속 오브젝트를 쿠버네티스 *고아*로 만들 수 있다. {{<version-check>}}
|
||||
|
||||
{{<tabs name="orphan_objects">}}
|
||||
{{% tab name="쿠버네티스 1.20.x 이후 버전" %}}
|
||||
|
||||
**kubectl 사용**
|
||||
|
||||
|
|
@ -293,52 +199,6 @@ kubectl delete deployment nginx-deployment --cascade=orphan
|
|||
...
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="쿠버네티스 1.20.x 전 버전" %}}
|
||||
|
||||
상세한 내용은 [쿠버네티스 버전에 따른 문서](/ko/docs/home/supported-doc-versions/)를 참고한다.
|
||||
|
||||
**kubectl 사용**
|
||||
|
||||
다음 명령어를 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl delete deployment nginx-deployment --cascade=orphan
|
||||
```
|
||||
|
||||
**쿠버네티스 API 사용**
|
||||
|
||||
1. 로컬 프록시 세션을 시작한다.
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
|
||||
1. 삭제를 작동시키기 위해 `curl`을 사용한다.
|
||||
|
||||
```shell
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
출력에는 다음과 같이 `finalizers` 필드에 `orphan`이 포함되어 있다.
|
||||
|
||||
```
|
||||
"kind": "Deployment",
|
||||
"apiVersion": "apps/v1",
|
||||
"namespace": "default",
|
||||
"uid": "6f577034-42a0-479d-be21-78018c466f1f",
|
||||
"creationTimestamp": "2021-07-09T16:46:37Z",
|
||||
"deletionTimestamp": "2021-07-09T16:47:08Z",
|
||||
"deletionGracePeriodSeconds": 0,
|
||||
"finalizers": [
|
||||
"orphan"
|
||||
],
|
||||
...
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{</tabs>}}
|
||||
|
||||
디플로이먼트가 관리하는 파드들이 계속 실행 중인지 확인할 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -170,6 +170,61 @@ type: Opaque
|
|||
|
||||
`YWRtaW5pc3RyYXRvcg==`는 `administrator`으로 디코딩된다.
|
||||
|
||||
## 시크릿(Secret) 작성 {#edit-secret}
|
||||
|
||||
매니페스트를 사용하여 생성한 시크릿의 데이터를 편집하려면, 매니페스트에서 `data`
|
||||
및 `stringData` 필드를 수정하고 해당 파일을 클러스터에 적용하면 된다.
|
||||
그렇지 않은 경우 기존의 `시크릿` 오브젝트를 편집할 수 있다.
|
||||
[수정 불가능한(immutable)](/docs/concepts/configuration/secret/#secret-immutable).
|
||||
|
||||
예를 들어, 이전 예제에서 패스워드를 `birdsarentreal`로 변경하려면,
|
||||
다음과 같이 수행한다.
|
||||
|
||||
1. 새로운 암호 문자열을 인코딩한다.
|
||||
|
||||
```shell
|
||||
echo -n 'birdsarentreal' | base64
|
||||
```
|
||||
|
||||
출력은 다음과 같다.
|
||||
|
||||
```
|
||||
YmlyZHNhcmVudHJlYWw=
|
||||
```
|
||||
|
||||
1. 새 암호 문자열로 `data` 필드를 업데이트 한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
password: YmlyZHNhcmVudHJlYWw=
|
||||
```
|
||||
|
||||
1. 클러스터에 매니페스트를 적용한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./secret.yaml
|
||||
```
|
||||
|
||||
출력은 다음과 같다.
|
||||
|
||||
```
|
||||
secret/mysecret configured
|
||||
```
|
||||
|
||||
쿠버네티스는 기존 `시크릿` 오브젝트를 업데이트한다. 자세히 보면, `kubectl` 도구는
|
||||
동일한 이름을 가진 기존 `Secret` 오브젝트가 있음을 알아낸다.
|
||||
`kubectl`은 기존의 오브젝트를 가져오고, 변경을 계획하며,
|
||||
변경된 `Secret` 오브젝트를 클러스터 컨트롤 플레인에 제출한다.
|
||||
|
||||
`kubectl apply --server-side`를 지정한 경우, `kubectl`은
|
||||
[서버 사이드 어플라이](/docs/reference/using-api/server-side-apply/)를 대신 사용한다.
|
||||
|
||||
## 삭제
|
||||
|
||||
생성한 시크릿을 삭제하려면 다음 명령을 실행한다.
|
||||
|
|
@ -183,4 +238,3 @@ kubectl delete secret mysecret
|
|||
- [시크릿 개념](/ko/docs/concepts/configuration/secret/)에 대해 자세히 알아보기
|
||||
- [kubectl을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 알아보기
|
||||
- [kustomize를 사용하여 시크릿을 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 알아보기
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue