Skip to content

Commit

Permalink
[ko] Update outdated files in dev-1.26.-ko.1 [M149-155]
Browse files Browse the repository at this point in the history 
Update outdated files in dev-1.26.-ko.1 [M149-155]
  • Loading branch information
@Virusuki
Virusuki committed May 13, 2023
1 parent bfd26ff commit 5cc285f
Show file tree
Hide file tree
Showing 7 changed files with 161 additions and 287 deletions.
12 changes: 11 additions & 1 deletion content/ko/docs/tasks/administer-cluster/cluster-upgrade.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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)을 참조한다.
169 changes: 58 additions & 111 deletions content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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 %}}

Expand All @@ -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) 구성을 상속한다.
Expand All @@ -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 구성으로 설치된다.

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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/) 읽기

8 changes: 4 additions & 4 deletions content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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>
```

## 워커 노드 업그레이드
Expand Down Expand Up @@ -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>
```

## 클러스터 상태 확인
Expand Down
8 changes: 8 additions & 0 deletions ...t/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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" >}}가
Expand Down
53 changes: 24 additions & 29 deletions .../docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -41,45 +41,40 @@ 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 install
```

위의 명령을 실행한 후, 이제 다음 명령으로 실리움(Cilium)을 설치할 수 있다.

```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 install
```

그런 다음 실리움은 자동으로 클러스터를 구성을 감지하고
성공적인 설치를 위해 적절한 구성요소를 만들고 설치한다.
구성요소는 다음과 같다.

- 시크릿 `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)의 보안 정책을
적용하는 방법을 설명한다.
Expand Down
Loading

0 comments on commit 5cc285f

Please sign in to comment.