kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #35677 from seokho-son/out-24-ko.2-m27-m30 

[ko] Update outdated files in dev-1.24-ko.2 (M27-M30)
pull/35767/head
Kubernetes Prow Robot 2022-08-05 18:22:17 -07:00 committed by GitHub
parent 8b5fa3ed1b 7f083cc80d
commit 983794988f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 250 additions and 145 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
content/ko/docs/concepts/security/controlling-access.md
View File

@ -1,9 +1,10 @@
--- ---
# reviewers:
# - erictune
# - lavalamp
title: 쿠버네티스 API 접근 제어하기 title: 쿠버네티스 API 접근 제어하기
content_type: concept content_type: concept
weight: 50
--- ---
<!-- overview --> <!-- overview -->
@ -164,7 +165,27 @@ API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수
- 요청이 어드미션 제어 모듈(들)에 의해 처리된다. - 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
- 인증 및 인가 모듈을 실행한다. - 인증 및 인가 모듈을 실행한다.
GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 `kube-up.sh`로 클러스터를 생성하면 ## {{% heading "whatsnext" %}}
API 서버는 포트 443에서 서비스한다.
GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다. 인증 및 인가 그리고 API 접근 제어에 대한 추가적인 문서는 아래에서 찾을 수 있다.
이외에 클러스터 설정 방법은 다양하다.
- [인증하기](/docs/reference/access-authn-authz/authentication/)
- [부트스트랩 토큰(bootstrap token)으로 인증하기](/docs/reference/access-authn-authz/bootstrap-tokens/)
- [어드미션 컨트롤러(admission controller)](/docs/reference/access-authn-authz/admission-controllers/)
- [동적 어드미션(admission) 제어](/docs/reference/access-authn-authz/extensible-admission-controllers/)
- [인가](/ko/docs/reference/access-authn-authz/authorization/)
- [역할 기반 접근 제어(role based access control)](/docs/reference/access-authn-authz/rbac/)
- [속성 기반 접근 제어(attribute based access control)](/docs/reference/access-authn-authz/abac/)
- [노드 인가](/docs/reference/access-authn-authz/node/)
- [웹훅(webhook) 인가](/docs/reference/access-authn-authz/webhook/)
- [인증서 서명 요청(Certificate Signing Request)](/docs/reference/access-authn-authz/certificate-signing-requests/)
- [CSR 승인](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) 및
[인증서 서명](/docs/reference/access-authn-authz/certificate-signing-requests/#signing) 포함하기
- 서비스 어카운트
- [개발자 가이드](/docs/tasks/configure-pod-container/configure-service-account/)
- [운영](/ko/docs/reference/access-authn-authz/service-accounts-admin/)
또한, 다음 사항을 익힐 수 있다.
- 파드가 API 크리덴셜(credential)을 얻기 위해
[시크릿(Secret)](/ko/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
을 사용하는 방법.

25
content/ko/docs/concepts/services-networking/_index.md
View File

@ -7,26 +7,25 @@ description: >
## 쿠버네티스 네트워크 모델 ## 쿠버네티스 네트워크 모델
모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다. 클러스터의 모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다.
이는 즉 `파드`간 연결을 명시적으로 만들 필요가 없으며 이는 즉 `파드`간 연결을 명시적으로 만들 필요가 없으며
또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다. 또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다.
이로 인해 포트 할당, 네이밍, 서비스 디스커버리, 이로 인해 포트 할당, 네이밍, 서비스 디스커버리,
[로드 밸런싱](/ko/docs/concepts/services-networking/ingress/#load-balancing), [로드 밸런싱](/ko/docs/concepts/services-networking/ingress/#load-balancing),
애플리케이션 구성, 마이그레이션 관점에서 `파드`를 애플리케이션 구성, 마이그레이션 관점에서 `파드`를 VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고
VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다. 하위 호환성을 갖는 모델이 제시된다.
쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다 쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다.
(이로 인해 모든 의도적인 네트워크 분할 정책이 방지된다) (이를 통해, 의도적인 네트워크 분할 정책을 방지)
* [노드](/ko/docs/concepts/architecture/nodes/) 상의 파드가 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다 * 파드는 NAT 없이 [노드](/ko/docs/concepts/architecture/nodes/) 상의 모든 파드와
* 노드 상의 에이전트(예: 시스템 데몬, kubelet)가 해당 노드의 모든 통신할 수 있다.
파드와 통신할 수 있다 * 노드 상의 에이전트(예: 시스템 데몬, kubelet)는 해당 노드의 모든
파드와 통신할 수 있다.
참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: 리눅스)에 대해서는 참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예:
다음의 요구사항도 존재한다. 리눅스)에 대해서는, 파드가 노드의 호스트 네트워크에 연결되어 있을 때에도 파드는 여전히
NAT 없이 모든 노드의 모든 파드와 통신할 수 있다.
* 한 노드의 호스트 네트워크에 있는 파드는
NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
이 모델은 전반적으로 덜 복잡할 뿐만 아니라, 이 모델은 전반적으로 덜 복잡할 뿐만 아니라,
무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다. 무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다.

27
content/ko/docs/concepts/services-networking/dns-pod-service.md
View File

@ -1,7 +1,7 @@
--- ---
# reviewers:
# - davidopp
# - thockin
title: 서비스 및 파드용 DNS title: 서비스 및 파드용 DNS
content_type: concept content_type: concept
weight: 20 weight: 20
@ -226,6 +226,7 @@ DNS 정책은 파드별로 설정할 수 있다.
확인할 수 있다. 확인할 수 있다.
- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 - "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
"`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다.
- 참고: 윈도우에서는 지원되지 않는다.상세 정보는 [아래](#dns-windows)에서 확인한다.
- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다. - "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다.
모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다. 모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다.
아래 절인 [파드의 DNS 설정](#pod-dns-config)에서 아래 절인 [파드의 DNS 설정](#pod-dns-config)에서
@ -306,7 +307,7 @@ IPv6 셋업을 위해서 검색 경로와 네임 서버 셋업은 다음과 같
kubectl exec -it dns-example -- cat /etc/resolv.conf kubectl exec -it dns-example -- cat /etc/resolv.conf
``` ```
출력은 다음과 같은 형식일 것이다. 출력은 다음과 같은 형식일 것이다.
```shell ```
nameserver fd00:79:30::a nameserver fd00:79:30::a
search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
options ndots:5 options ndots:5
@ -323,6 +324,24 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화
쿠버네티스는 최대 32개의 탐색 도메인과 쿠버네티스는 최대 32개의 탐색 도메인과
최대 2048자의 탐색 도메인 목록을 허용한다. 최대 2048자의 탐색 도메인 목록을 허용한다.
## 윈도우 노드에서 DNS 해석(resolution) {#dns-windows}
- ClusterFirstWithHostNet은 윈도우 노드에서 구동 중인 파드에는 지원되지 않는다.
윈도우는 `.`를 포함한 모든 네임(주소)을 FQDN으로 취급하여 FQDN 해석을 생략한다.
- 윈도우에는 여러 DNS 해석기가 사용될 수 있다. 이러한 해석기는
각자 조금씩 다르게 동작하므로, 네임 쿼리 해석을 위해서
[`Resolve-DNSName`](https://docs.microsoft.com/powershell/module/dnsclient/resolve-dnsname)
파워쉘(powershell) cmdlet을 사용하는 것을 추천한다.
- 리눅스에는 DNS 접미사 목록이 있는데, 이는 네임이 완전한 주소가 아니어서 주소
해석에 실패한 경우 사용한다.
윈도우에서는 파드의 네임스페이스(예: `mydns.svc.cluster.local`)와 연계된
하나의 DNS 접미사만 가질 수 있다. 윈도우는 이러한 단일 접미사 통해 해석될 수 있는
FQDNs, 서비스, 또는 네트워크 네임을 해석할 수 있다. 예를 들어, `default`에
소속된 파드는 DNS 접미사 `default.svc.cluster.local`를 가진다.
윈도우 파드 내부에서는 `kubernetes.default.svc.cluster.local`와
`kubernetes`를 모두 해석할 수 있다. 그러나, 일부에만 해당(partially qualified)하는 네임(`kubernetes.default` 또는
`kubernetes.default.svc`)은 해석할 수 없다.
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}

308
content/ko/docs/concepts/services-networking/dual-stack.md
View File

@ -1,16 +1,15 @@
--- ---
title: IPv4/IPv6 이중 스택 title: IPv4/IPv6 이중 스택
feature: feature:
title: IPv4/IPv6 이중 스택 title: IPv4/IPv6 이중 스택
description: > description: >
파드와 서비스에 IPv4와 IPv6 주소 할당 파드와 서비스에 IPv4와 IPv6 주소 할당
content_type: concept content_type: concept
# reviewers:
# - lachie83
# - khenidak
# - aramase
# - bridgetkromhout
weight: 70 weight: 70
--- ---
@ -18,11 +17,11 @@ weight: 70
{{< feature-state for_k8s_version="v1.23" state="stable" >}} {{< feature-state for_k8s_version="v1.23" state="stable" >}}
IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다. IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와
{{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다.
IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있고, IPv4 및 IPv6 주소를 동시에 할당할 수 있다.
IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터에 기본적으로
활성화되어 있고, IPv4 및 IPv6 주소를 동시에 할당할 수 있다.
<!-- body --> <!-- body -->
@ -38,60 +37,70 @@ IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터
IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음의 필수 구성 요소가 필요하다. IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음의 필수 구성 요소가 필요하다.
* 쿠버네티스 1.20 이상 * 쿠버네티스 1.20 및 이후 버전
이전 버전과 함께 이중 스택 서비스를 사용하는 방법에 대한 정보
쿠버네티스 버전, 쿠버네티스 해당 버전에 대한 예전 버전 쿠버네티스에서 이중 스택 서비스를 사용하는
문서 참조 방법에 대한 정보는 해당 버전의 쿠버네티스에 대한
* 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.) 문서를 참조한다.
* 이중 스택 네트워킹을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
* 이중 스택 네트워킹을 위한 공급자의 지원. (클라우드 공급자 또는 다른 방식으로
쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 함.)
* 이중 스택 네트워킹을 지원하는
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/).
## IPv4/IPv6 이중 스택 구성 ## IPv4/IPv6 이중 스택 구성
IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다. IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다.
* kube-apiserver: * kube-apiserver:
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>` * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
* kube-controller-manager: * kube-controller-manager:
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>` * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>` * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다. * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
* kube-proxy: * kube-proxy:
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>` * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* kubelet: * kubelet:
* `--cloud-provider`가 명시되지 않았다면 * `--cloud-provider`가 명시되지 않았다면 관리자는 해당 노드에 듀얼 스택
관리자는 해당 노드에 듀얼 스택 `.status.addresses`를 수동으로 설정하기 위해 `.status.addresses`를 수동으로 설정하기 위해 쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다.
쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다. 해당 노드의 파드가 HostNetwork 모드로 실행된다면,
해당 노드의 파드가 HostNetwork 모드로 실행된다면, 파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다.
파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다. 노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된
노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된 IP 패밀리 선호사항을 만족한다.
IP 패밀리 선호사항을 만족한다.
{{< note >}} {{< note >}}
IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도) IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도)
IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.) IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한
주소는 아니다. [RFC 4193](https://tools.ietf.org/html/rfc4193)을 확인한다.)
{{< /note >}} {{< /note >}}
## 서비스 ## 서비스
IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 생성할 수 있다. IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 생성할 수 있다.
서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성) 서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다.
(`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성)
서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를 서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를
다음 값 중 하나로 설정한다. 다음 값 중 하나로 설정한다.
* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다. * `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스
클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
* `PreferDualStack`: * `PreferDualStack`:
* 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다.
* `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다. * `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다.
* `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다. * `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로
`.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다.
단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의 순서를 정의하려는 경우, 서비스에서 옵션 필드 `.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다. 단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의
순서를 정의하려는 경우, 서비스에서 옵션 필드
`.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다.
{{< note >}} {{< note >}}
`.spec.ipFamilies` 필드는 이미 존재하는 서비스에 `.spec.ClusterIP`를 재할당할 수 없기 때문에 변경할 수 없다. `.spec.ipFamilies`를 변경하려면 서비스를 삭제하고 다시 생성한다. `.spec.ipFamilies` 필드는 이미 존재하는 서비스에 `.spec.ClusterIP`를
재할당할 수 없기 때문에 변경할 수 없다. `.spec.ipFamilies`를 변경하려면
서비스를 삭제하고 다시 생성한다.
{{< /note >}} {{< /note >}}
`.spec.ipFamilies`를 다음 배열 값 중 하나로 설정할 수 있다. `.spec.ipFamilies`를 다음 배열 값 중 하나로 설정할 수 있다.
@ -109,139 +118,196 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서
#### 새로운 서비스에 대한 이중 스택 옵션 #### 새로운 서비스에 대한 이중 스택 옵션
1. 이 서비스 사양은 `.spec.ipFamilyPolicy`를 명시적으로 정의하지 않는다. 이 서비스를 만들 때 쿠버네티스는 처음 구성된 `service-cluster-ip-range`에서 서비스에 대한 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy`를 `SingleStack`으로 설정한다. ([셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)와 같은 방식으로 동작한다.) 1. 이 서비스 사양은 `.spec.ipFamilyPolicy`를 명시적으로 정의하지 않는다.
이 서비스를 만들 때 쿠버네티스는 처음 구성된 `service-cluster-ip-range`에서
서비스에 대한 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy`를
`SingleStack`으로 설정한다. ([셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)와
같은 방식으로 동작한다.)
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
1. 이 서비스 사양은 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 명시적으로 정의한다. 이중 스택 클러스터에서 이 서비스를 생성하면 쿠버네티스는 서비스에 대해 IPv4 및 IPv6 주소를 모두 할당한다. 컨트롤 플레인은 서비스의 `.spec`을 업데이트하여 IP 주소 할당을 기록한다. 필드 `.spec.ClusterIPs`는 기본 필드이며 할당된 IP 주소를 모두 포함한다. `.spec.ClusterIP`는 값이 `.spec.ClusterIPs`에서 계산된 보조 필드이다. 1. 이 서비스 사양은 `.spec.ipFamilyPolicy`에 `PreferDualStack`을
명시적으로 정의한다. 이중 스택 클러스터에서 이 서비스를 생성하면 쿠버네티스는
서비스에 대해 IPv4 및 IPv6 주소를 모두 할당한다. 컨트롤 플레인은 서비스의
`.spec`을 업데이트하여 IP 주소 할당을 기록한다. 필드 `.spec.ClusterIPs`는
기본 필드이며 할당된 IP 주소를 모두 포함한다. `.spec.ClusterIP`는 값이
`.spec.ClusterIPs`에서 계산된 보조 필드이다.
* `.spec.ClusterIP` 필드의 경우 컨트롤 플레인은 첫 번째 서비스 클러스터 IP 범위와 동일한 주소 계열의 IP 주소를 기록한다. * `.spec.ClusterIP` 필드의 경우 컨트롤 플레인은 첫 번째 서비스 클러스터 IP
* 단일 스택 클러스터에서 `.spec.ClusterIPs` 및 `.spec.ClusterIP` 필드는 모두 하나의 주소만 나열한다. 범위와 동일한 주소 계열의 IP 주소를 기록한다.
* 이중 스택이 활성화된 클러스터에서 `.spec.ipFamilyPolicy`에 `RequireDualStack`을 지정하면 `PreferDualStack`과 동일하게 작동한다. * 단일 스택 클러스터에서 `.spec.ClusterIPs` 및 `.spec.ClusterIP` 필드는
모두 하나의 주소만 나열한다.
* 이중 스택이 활성화된 클러스터에서 `.spec.ipFamilyPolicy`에 `RequireDualStack`을
지정하면 `PreferDualStack`과 동일하게 작동한다.
{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}} {{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}}
1. 이 서비스 사양은 `.spec.ipFamilies`에` IPv6`과 `IPv4`를 명시적으로 정의하고 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 정의한다. 쿠버네티스가 `.spec.ClusterIPs`에 IPv6 및 IPv4 주소를 할당할 때 `.spec.ClusterIP`는 `.spec.ClusterIPs` 배열의 첫 번째 요소이므로 IPv6 주소로 설정되어 기본값을 재정의한다. 1. 이 서비스 사양은 `.spec.ipFamilies`에` IPv6`과 `IPv4`를 명시적으로 정의하고
`.spec.ipFamilyPolicy`에 `PreferDualStack`을 정의한다. 쿠버네티스가 `.spec.ClusterIPs`에
IPv6 및 IPv4 주소를 할당할 때 `.spec.ClusterIP`는 `.spec.ClusterIPs` 배열의
첫 번째 요소이므로 IPv6 주소로 설정되어 기본값을 재정의한다.
{{< codenew file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" >}} {{< codenew file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" >}}
#### 기존 서비스의 이중 스택 기본값 #### 기존 서비스의 이중 스택 기본값
이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면 이중 스택이 활성화된다.) 이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된
경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면
이중 스택이 활성화된다.)
1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다. 1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이
`.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고
`.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다.
기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다.
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
kubectl을 사용하여 기존 서비스를 검사하여 이 동작을 검증할 수 있다. kubectl을 사용하여 기존 서비스를 검사하여 이 동작을 검증할 수 있다.
```shell ```shell
kubectl get svc my-service -o yaml kubectl get svc my-service -o yaml
``` ```
```yaml ```yaml
apiVersion: v1 apiVersion: v1
kind: Service kind: Service
metadata: metadata:
labels: labels:
app: MyApp app: MyApp
name: my-service name: my-service
spec: spec:
clusterIP: 10.0.197.123 clusterIP: 10.0.197.123
clusterIPs: clusterIPs:
- 10.0.197.123 - 10.0.197.123
ipFamilies: ipFamilies:
- IPv4 - IPv4
ipFamilyPolicy: SingleStack ipFamilyPolicy: SingleStack
ports: ports:
- port: 80 - port: 80
protocol: TCP protocol: TCP
targetPort: 80 targetPort: 80
selector: selector:
app: MyApp app: MyApp
type: ClusterIP type: ClusterIP
status: status:
loadBalancer: {} loadBalancer: {}
``` ```
1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-apiserver에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다. 1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는
`.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을
`SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스
클러스터 IP 범위(kube-apiserver에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로
지정한다.
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
kubectl을 사용하여 셀렉터로 기존 헤드리스 서비스를 검사하여 이 동작의 유효성을 검사 할 수 있다. kubectl을 사용하여 셀렉터로 기존 헤드리스 서비스를 검사하여 이 동작의 유효성을 검사 할 수 있다.
```shell ```shell
kubectl get svc my-service -o yaml kubectl get svc my-service -o yaml
``` ```
```yaml ```yaml
apiVersion: v1 apiVersion: v1
kind: Service kind: Service
metadata: metadata:
labels: labels:
app: MyApp app: MyApp
name: my-service name: my-service
spec: spec:
clusterIP: None clusterIP: None
clusterIPs: clusterIPs:
- None - None
ipFamilies: ipFamilies:
- IPv4 - IPv4
ipFamilyPolicy: SingleStack ipFamilyPolicy: SingleStack
ports: ports:
- port: 80 - port: 80
protocol: TCP protocol: TCP
targetPort: 80 targetPort: 80
selector: selector:
app: MyApp app: MyApp
``` ```
#### 단일 스택과 이중 스택 간 서비스 전환 #### 단일 스택과 이중 스택 간 서비스 전환
서비스는 단일 스택에서 이중 스택으로, 이중 스택에서 단일 스택으로 변경할 수 있다. 서비스는 단일 스택에서 이중 스택으로, 이중 스택에서 단일 스택으로 변경할 수 있다.
1. 서비스를 단일 스택에서 이중 스택으로 변경하려면 원하는 대로 `.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack` 또는 `RequireDualStack`으로 변경한다. 이 서비스를 단일 스택에서 이중 스택으로 변경하면 쿠버네티스는 누락된 주소 계열의 것을 배정하므로 해당 서비스는 이제 IPv4와 IPv6 주소를 갖게된다. 1. 서비스를 단일 스택에서 이중 스택으로 변경하려면 원하는 대로 `.spec.ipFamilyPolicy`를
`SingleStack`에서 `PreferDualStack` 또는 `RequireDualStack`으로 변경한다.
이 서비스를 단일 스택에서 이중 스택으로 변경하면 쿠버네티스는 누락된 주소 계열의
것을 배정하므로 해당 서비스는 이제 IPv4와 IPv6 주소를 갖는다.
`.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack`으로 업데이트하는 서비스 사양을 편집한다. `.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack`으로 업데이트하는 서비스 사양을 편집한다.
이전: 이전:
```yaml
spec:
ipFamilyPolicy: SingleStack
```
이후:
```yaml
spec:
ipFamilyPolicy: PreferDualStack
```
1. 서비스를 이중 스택에서 단일 스택으로 변경하려면 `.spec.ipFamilyPolicy`를 `PreferDualStack`에서 또는 `RequireDualStack`을 `SingleStack`으로 변경한다. 이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 `.spec.ClusterIPs` 배열의 첫 번째 요소 만 유지하고 `.spec.ClusterIP`를 해당 IP 주소로 설정하고 `.spec.ipFamilies`를 `.spec.ClusterIPs`의 주소 계열로 설정한다. ```yaml
spec:
ipFamilyPolicy: SingleStack
```
이후:
```yaml
spec:
ipFamilyPolicy: PreferDualStack
```
1. 서비스를 이중 스택에서 단일 스택으로 변경하려면 `.spec.ipFamilyPolicy`를
`PreferDualStack`에서 또는 `RequireDualStack`을 `SingleStack`으로 변경한다.
이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 `.spec.ClusterIPs`
배열의 첫 번째 요소 만 유지하고 `.spec.ClusterIP`를 해당 IP 주소로 설정하고
`.spec.ipFamilies`를 `.spec.ClusterIPs`의 주소 계열로 설정한다.
### 셀렉터가 없는 헤드리스 서비스 ### 셀렉터가 없는 헤드리스 서비스
[셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 `.spec.ipFamilyPolicy`가 명시적으로 설정되지 않은 경우 `.spec.ipFamilyPolicy` 필드의 기본값은 `RequireDualStack` 이다. [셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 `.spec.ipFamilyPolicy`가
명시적으로 설정되지 않은 경우 `.spec.ipFamilyPolicy` 필드의 기본값은
`RequireDualStack` 이다.
### 로드밸런서 서비스 유형 ### 로드밸런서 서비스 유형
서비스에 이중 스택 로드밸런서를 프로비저닝하려면 서비스에 이중 스택 로드밸런서를 프로비저닝하려면
* `.spec.type` 필드를 `LoadBalancer`로 설정
* `.spec.ipFamilyPolicy` 필드를 `PreferDualStack` 또는 `RequireDualStack`으로 설정 * `.spec.type` 필드를 `LoadBalancer`로 설정
* `.spec.ipFamilyPolicy` 필드를 `PreferDualStack` 또는 `RequireDualStack`으로 설정
{{< note >}} {{< note >}}
이중 스택 `LoadBalancer` 유형 서비스를 사용하려면 클라우드 공급자가 IPv4 및 IPv6로드 밸런서를 지원해야 한다. 이중 스택 `LoadBalancer` 유형 서비스를 사용하려면 클라우드 공급자가
IPv4 및 IPv6로드 밸런서를 지원해야 한다.
{{< /note >}} {{< /note >}}
## 이그레스(Egress) 트래픽 ## 이그레스(Egress) 트래픽
비공개로 라우팅할 수 있는 IPv6 주소를 사용하는 파드에서 클러스터 외부 대상 (예: 공용 인터넷)에 도달하기 위해 이그레스 트래픽을 활성화하려면 투명 프록시 또는 IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주소를 사용하도록 파드를 활성화해야 한다. [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) 프로젝트는 이중 스택 클러스터에서 IP 위장을 지원한다. 비공개로 라우팅할 수 있는 IPv6 주소를 사용하는 파드에서 클러스터 외부 대상
(예: 공용 인터넷)에 도달하기 위해 이그레스 트래픽을 활성화하려면 투명 프록시 또는
IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주소를 사용하도록 파드를 활성화해야 한다.
[ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)
프로젝트는 이중 스택 클러스터에서 IP 위장을 지원한다.
{{< note >}} {{< note >}}
{{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 IPv6를 지원하는지 확인한다. {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 IPv6를 지원하는지 확인한다.
{{< /note >}} {{< /note >}}
## 윈도우 지원
윈도우에 있는 쿠버네티스는 싱글 스택(single-stack) "IPv6-only" 네트워킹을 지원하지 않는다. 그러나, 싱글 패밀리(single-family)
서비스로 되어 있는 파드와 노드에 대해서는 듀얼 스택(dual-stack) IPv4/IPv6 네트워킹을
지원한다.
`l2bridge` 네트워크로 IPv4/IPv6 듀얼 스택 네트워킹을 사용할 수 있다.
{{< note >}}
윈도우에서 오버레이 (VXLAN) 네트워크은 듀얼 스택 네트워킹을 **지원하지 않는다.**
{{< /note >}}
윈도우의 다른 네트워크 모델에 대한 내용은
[윈도우에서의 네트워킹](/docs/concepts/services-networking/windows-networking#network-modes)을 살펴본다.
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
* [IPv4/IPv6 이중 스택 검증](/ko/docs/tasks/network/validate-dual-stack) 네트워킹 * [IPv4/IPv6 이중 스택 검증](/ko/docs/tasks/network/validate-dual-stack) 네트워킹
* [kubeadm을 사용하여 이중 스택 네트워킹 활성화 * [kubeadm을 사용하여 이중 스택 네트워킹 활성화](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)
](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)