[ko] Update outdated files in dev-1.21-ko.1 (p2)
This commit is contained in:
Jihoon Seo
@@ -19,22 +19,22 @@ content_type: task
|
||||
|
||||
쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/),
|
||||
[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
|
||||
고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수
|
||||
없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서
|
||||
도달할 수 없다.
|
||||
고유한 IP를 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
|
||||
클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서
|
||||
접근할 수 없을 것이다.
|
||||
|
||||
### 연결하는 방법
|
||||
|
||||
클러스터 외부에서 노드, 파드 및 서비스에 연결하기 위한 몇 가지 옵션이 있다.
|
||||
클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다.
|
||||
|
||||
- 퍼블릭 IP를 통해 서비스에 접근한다.
|
||||
- `NodePort` 또는 `LoadBalancer` 타입의 서비스를 사용하여 해당 서비스를 클러스터 외부에서
|
||||
접근할 수 있게 한다. [서비스](/ko/docs/concepts/services-networking/service/)와
|
||||
- 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의
|
||||
서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와
|
||||
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참고한다.
|
||||
- 클러스터 환경에 따라, 서비스는 단지 회사 네트워크에 노출되기도 하며,
|
||||
인터넷에 노출되는 경우도 있다. 노출되는 서비스가 안전한지 생각한다.
|
||||
자체 인증을 수행하는가?
|
||||
- 서비스 뒤에 파드를 배치한다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면,
|
||||
- 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며,
|
||||
인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
|
||||
해당 서비스는 자체적으로 인증을 수행하는가?
|
||||
- 파드는 서비스 뒤에 위치시킨다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면,
|
||||
파드에 고유한 레이블을 배치하고 이 레이블을 선택하는 새 서비스를 생성한다.
|
||||
- 대부분의 경우, 애플리케이션 개발자가 nodeIP를 통해 노드에 직접
|
||||
접근할 필요는 없다.
|
||||
@@ -54,8 +54,8 @@ content_type: task
|
||||
|
||||
### 빌트인 서비스 검색
|
||||
|
||||
일반적으로, kube-system에 의해 클러스터에서 시작되는 몇 가지 서비스가 있다. `kubectl cluster-info` 명령을
|
||||
사용하여 이들의 목록을 얻는다.
|
||||
일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다.
|
||||
`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl cluster-info
|
||||
|
||||
@@ -33,8 +33,8 @@ Kube-dns의 배포나 교체에 관한 매뉴얼은 [CoreDNS GitHub 프로젝트
|
||||
### Kubeadm을 사용해 기존 클러스터 업그레이드하기
|
||||
|
||||
쿠버네티스 버전 1.10 이상에서, `kube-dns` 를 사용하는 클러스터를 업그레이드하기 위하여
|
||||
`kubeadm` 을 사용할 때 CoreDNS로 이동할 수도 있다. 이 경우, `kubeadm` 은
|
||||
`kube-dns` 컨피그맵(ConfigMap)을 기반으로 패더레이션, 스텁 도메인(stub domain), 업스트림 네임 서버의
|
||||
`kubeadm` 을 사용할 때 CoreDNS로 전환할 수도 있다. 이 경우, `kubeadm` 은
|
||||
`kube-dns` 컨피그맵(ConfigMap)을 기반으로 스텁 도메인(stub domain), 업스트림 네임 서버의
|
||||
설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다.
|
||||
|
||||
만약 kube-dns에서 CoreDNS로 이동하는 경우, 업그레이드 과정에서 기능 게이트의 `CoreDNS` 값을 `true` 로 설정해야 한다.
|
||||
@@ -44,8 +44,6 @@ kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
|
||||
```
|
||||
|
||||
쿠버네티스 1.13 이상에서 기능 게이트의 `CoreDNS` 항목은 제거되었으며, CoreDNS가 기본적으로 사용된다.
|
||||
업그레이드된 클러스터에서 kube-dns를 사용하려는 경우, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에
|
||||
설명된 지침 가이드를 참고하자.
|
||||
|
||||
1.11 미만 버전일 경우 업그레이드 과정에서 만들어진 파일이 Corefile을 **덮어쓴다**.
|
||||
**만약 컨피그맵을 사용자 정의한 경우, 기존의 컨피그맵을 저장해야 한다.** 새 컨피그맵이
|
||||
@@ -54,26 +52,7 @@ kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
|
||||
만약 쿠버네티스 1.11 이상 버전에서 CoreDNS를 사용하는 경우, 업그레이드 과정에서,
|
||||
기존의 Corefile이 유지된다.
|
||||
|
||||
|
||||
### Kubeadm을 사용해 CoreDNS가 아닌 kube-dns 설치하기
|
||||
|
||||
{{< note >}}
|
||||
쿠버네티스 1.11 버전에서, CoreDNS는 GA(General Availability) 되었으며,
|
||||
기본적으로 설치된다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< warning >}}
|
||||
쿠버네티스 1.18 버전에서, kubeadm을 통한 kube-dns는 사용 중단되었으며, 향후 버전에서 제거될 예정이다.
|
||||
{{< /warning >}}
|
||||
|
||||
1.13 보다 이전 버전에서 kube-dns를 설치하는경우, 기능 게이트의 `CoreDNS`
|
||||
값을 `false` 로 변경해야 한다.
|
||||
|
||||
```
|
||||
kubeadm init --feature-gates=CoreDNS=false
|
||||
```
|
||||
|
||||
1.13 이후 버전에서는, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 설명된 지침 가이드를 참고하자.
|
||||
쿠버네티스 버전 1.21에서, kubeadm 의 `kube-dns` 지원 기능이 삭제되었다.
|
||||
|
||||
## CoreDNS 업그레이드하기
|
||||
|
||||
|
||||
@@ -31,7 +31,7 @@ DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io
|
||||
CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다.
|
||||
|
||||
{{< note >}}
|
||||
CoreDNS와 kube-dns 서비스 모두 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다.
|
||||
CoreDNS 서비스는 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다.
|
||||
이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -176,17 +176,14 @@ kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을
|
||||
|
||||
CoreDNS는 kube-dns 이상의 기능을 지원한다.
|
||||
`StubDomains` 과 `upstreamNameservers` 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 `forward` 플러그인으로 변환된다.
|
||||
마찬가지로, kube-dns의 `Federations` 플러그인은 CoreDNS의 `federation` 플러그인으로 변환된다.
|
||||
|
||||
### 예시
|
||||
|
||||
kube-dns에 대한 이 컨피그맵 예제는 federations, stubDomains 및 upstreamNameservers를 지정한다.
|
||||
kube-dns에 대한 이 컨피그맵 예제는 stubDomains 및 upstreamNameservers를 지정한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
federations: |
|
||||
{"foo" : "foo.feddomain.com"}
|
||||
stubDomains: |
|
||||
{"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]}
|
||||
upstreamNameservers: |
|
||||
@@ -196,13 +193,6 @@ kind: ConfigMap
|
||||
|
||||
CoreDNS에서는 동등한 설정으로 Corefile을 생성한다.
|
||||
|
||||
* federations 에 대응하는 설정:
|
||||
```
|
||||
federation cluster.local {
|
||||
foo foo.feddomain.com
|
||||
}
|
||||
```
|
||||
|
||||
* stubDomains 에 대응하는 설정:
|
||||
```yaml
|
||||
abc.com:53 {
|
||||
|
||||
@@ -168,7 +168,7 @@ controllerManager:
|
||||
|
||||
### 인증서 서명 요청(CSR) 생성
|
||||
|
||||
쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다.
|
||||
쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다.
|
||||
|
||||
## 외부 CA로 인증서 갱신
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ weight: 20
|
||||
|
||||
### 추가 정보
|
||||
|
||||
- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)이
|
||||
- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](/docs/tasks/administer-cluster/safely-drain-node/)이
|
||||
필요하다. 컨트롤 플레인 노드의 경우 CoreNDS 파드 또는 기타 중요한 워크로드를 실행할 수 있다.
|
||||
- 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다.
|
||||
|
||||
@@ -328,7 +328,7 @@ etcd 업그레이드가 실패하고 자동 롤백이 작동하지 않으면,
|
||||
- 컨트롤 플레인 이미지가 사용 가능한지 또는 머신으로 가져올 수 있는지 확인한다.
|
||||
- 컴포넌트 구성에 버전 업그레이드가 필요한 경우 대체 구성을 생성하거나 사용자가 제공한 것으로 덮어 쓰기한다.
|
||||
- 컨트롤 플레인 컴포넌트 또는 롤백 중 하나라도 나타나지 않으면 업그레이드한다.
|
||||
- 새로운 `kube-dns` 와 `kube-proxy` 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다.
|
||||
- 새로운 `CoreDNS` 와 `kube-proxy` 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다.
|
||||
- API 서버의 새 인증서와 키 파일을 작성하고 180일 후에 만료될 경우 이전 파일을 백업한다.
|
||||
|
||||
`kubeadm upgrade node` 는 추가 컨트롤 플레인 노드에서 다음을 수행한다.
|
||||
|
||||
+1
-1
@@ -18,7 +18,7 @@ weight: 10
|
||||
|
||||
**사전요구사항**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts).
|
||||
|
||||
1. 캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가하면 된다.
|
||||
1. 캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가한다.
|
||||
|
||||
**문법**
|
||||
```shell
|
||||
|
||||
Reference in New Issue
Block a user