diff --git a/content/ko/docs/tasks/administer-cluster/cluster-upgrade.md b/content/ko/docs/tasks/administer-cluster/cluster-upgrade.md index 14fec25606..972c36c08f 100644 --- a/content/ko/docs/tasks/administer-cluster/cluster-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/cluster-upgrade.md @@ -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)을 참조한다. diff --git a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md index 3585127c97..b88cfa4c9b 100644 --- a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.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 확인자 정보를 각 컨테이너에 전달한다. +CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, +일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다. +Kubelet 은 `--cluster-dns=` 플래그를 사용하여 +DNS 확인자 정보를 각 컨테이너에 전달한다. DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-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/) 읽기 + diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 0dfe0865d6..5143c80379 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -208,8 +208,8 @@ sudo kubeadm upgrade apply - 노드를 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 전환한다. ```shell - # 을 드레인하려는 노드의 이름으로 바꾼다. - kubectl uncordon + # 을 드레인하려는 노드의 이름으로 바꾼다. + kubectl uncordon ``` ## 워커 노드 업그레이드 @@ -289,8 +289,8 @@ sudo kubeadm upgrade apply - 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 만든다. ```shell - # 을 노드의 이름으로 바꾼다. - kubectl uncordon + # 을 노드의 이름으로 바꾼다. + kubectl uncordon ``` ## 클러스터 상태 확인 diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index ad6885313e..8b36c28afc 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -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" >}}가 diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md index 426aeda7f2..a112f71f25 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -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)의 보안 정책을 diff --git a/content/ko/docs/tasks/administer-cluster/use-cascading-deletion.md b/content/ko/docs/tasks/administer-cluster/use-cascading-deletion.md index 2e44d61f64..fdb9b9c3a0 100644 --- a/content/ko/docs/tasks/administer-cluster/use-cascading-deletion.md +++ b/content/ko/docs/tasks/administer-cluster/use-cascading-deletion.md @@ -47,8 +47,7 @@ apiVersion: v1 `kubectl` 또는 쿠버네티스 API를 사용해 포그라운드 캐스케이딩 삭제로 전환할 수 있다. {{}} -{{}} -{{% 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` {{}}가 포함되어 있다. - - ``` - "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 %}} -{{}} ## 백그라운드 캐스케이딩 삭제 사용 {#use-background-cascading-deletion} @@ -144,8 +102,6 @@ kubectl delete deployment nginx-deployment --cascade=foreground 1. 클러스터를 실행하는 쿠버네티스 버전에 따라 디플로이먼트를 삭제하기 위해 `kubectl` 또는 쿠버네티스 API를 사용한다. {{}} -{{}} -{{% 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 %}} -{{}} ## 소유자 오브젝트 및 종속된 고아(orphan) 오브젝트 삭제 {#set-orphan-deletion-policy} @@ -250,8 +158,6 @@ kubectl delete deployment nginx-deployment --cascade=true 쿠버네티스 버전에 따라 `kubectl` 또는 쿠버네티스 API를 사용해 종속 오브젝트를 쿠버네티스 *고아*로 만들 수 있다. {{}} -{{}} -{{% 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 %}} -{{}} 디플로이먼트가 관리하는 파드들이 계속 실행 중인지 확인할 수 있다. diff --git a/content/ko/docs/tasks/configmap-secret/managing-secret-using-config-file.md b/content/ko/docs/tasks/configmap-secret/managing-secret-using-config-file.md index 2c38246834..2b1b6ce9ba 100644 --- a/content/ko/docs/tasks/configmap-secret/managing-secret-using-config-file.md +++ b/content/ko/docs/tasks/configmap-secret/managing-secret-using-config-file.md @@ -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/)하는 방법 알아보기 -