whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[ko] Update outdated files in dev-1.24-ko.1 M34-M48

Browse Source
This commit is contained in:
Jihoon Seo
2022-05-27 11:17:30 +09:00
parent e6d993feb3
commit 52738ce04b
15 changed files with 317 additions and 188 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/services-networking/dns-pod-service.md
-11
View File
@@ -323,17 +323,6 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화
쿠버네티스는 최대 32개의 탐색 도메인과
최대 2048자의 탐색 도메인 목록을 허용한다.
### 기능 가용성
파드 DNS 환경 설정 기능과 DNS 정책 "`None`" 기능의 쿠버네티스 버전별 가용성은 다음과 같다.
| 쿠버네티스 버전 | 기능 지원 |
| :---------: |:-----------:|
| 1.14 | 안정 |
| 1.10 | 베타 (기본값으로 켜져 있음)|
| 1.9 | 알파 |
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/services-networking/dual-stack.md
+1 -1
View File
@@ -43,7 +43,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음
쿠버네티스 버전, 쿠버네티스 해당 버전에 대한
문서 참조
* 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
* 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
* 이중 스택 네트워킹을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
## IPv4/IPv6 이중 스택 구성
content/ko/docs/concepts/services-networking/endpoint-slices.md
+8 -6
View File
@@ -1,4 +1,6 @@
---
title: 엔드포인트슬라이스
content_type: concept
weight: 45
@@ -144,12 +146,12 @@ endpoints:
v1 API에서는, 전용 필드 `nodeName` 및 `zone` 을 위해 엔드 포인트별
`topology` 가 효과적으로 제거되었다.
`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를
설정하는 것은 더 이상 사용되지 않으며, v1 API에서 지원되지 않는다. 대신,
v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. 이러한
필드는 API 버전 간에 자동으로 번역된다. 예를 들어,
v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`
키 값은 v1 API의 `zone` 필드로 접근할 수 있다.
`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를 설정하는 것은
더 이상 사용되지 않으며 v1 API에서 지원되지 않는다.
대신, v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다.
이러한 필드는 API 버전 간에 자동으로 번역된다.
예를 들어, v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"` 키 값은
v1 API의 `zone` 필드로 접근할 수 있다.
{{< /note >}}
### 관리
content/ko/docs/concepts/services-networking/ingress-controllers.md
+2 -1
View File
@@ -23,7 +23,7 @@ weight: 40
{{% thirdparty-content %}}
* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://docs.microsoft.com/azure/application-gateway/tutorial-ingress-controller-add-on-existing?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Faks%2Ftoc.json&bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com/azure/application-gateway/overview)를 구성하는 인그레스 컨트롤러다.
* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
컨트롤러다.
* [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다.
@@ -48,6 +48,7 @@ weight: 40
구동하는 인그레스 컨트롤러다.
* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx-ingress-controller/)는 [NGINX](https://www.nginx.com/resources/glossary/nginx/)
웹서버(프록시로 사용)와 함께 작동한다.
* [Pomerium 인그레스 컨트롤러](https://www.pomerium.com/docs/k8s/ingress.html)는 [Pomerium](https://pomerium.com/) 기반 인그레스 컨트롤러이며, 상황 인지 접근 정책을 제공한다.
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
* [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
[Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다.
content/ko/docs/concepts/services-networking/ingress.md
+10 -4
View File
@@ -74,7 +74,7 @@ graph LR;
{{< codenew file="service/networking/minimal-ingress.yaml" >}}
다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다.
인그레스에는 `apiVersion`, `kind`, `metadata` 및 `spec` 필드가 명시되어야 한다.
인그레스 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
@@ -118,8 +118,14 @@ graph LR;
### DefaultBackend {#default-backend}
규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. `defaultBackend` 는 일반적으로
[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송하며,
`.spec.defaultBackend`는 이와 같은 경우에 요청을 처리할 백엔드를 지정한다.
`defaultBackend` 는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며,
인그레스 리소스에 지정되어 있지 않다.
`.spec.rules` 가 명시되어 있지 않으면,
`.spec.defaultBackend` 는 반드시 명시되어 있어야 한다.
`defaultBackend` 가 설정되어 있지 않으면, 어느 규칙에도 해당되지 않는 요청의 처리는 인그레스 컨트롤러의 구현을 따른다(이러한
경우를 어떻게 처리하는지 알아보려면 해당 인그레스 컨트롤러 문서를 참고한다).
만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
기본 백엔드로 라우팅 된다.
@@ -309,7 +315,7 @@ spec:
controller: example.com/ingress-controller
parameters:
# 이 인그레스클래스에 대한 파라미터는
# "external-configuration" 환경 설정 네임스페이스에 있는
# "external-configuration" 네임스페이스에 있는
# "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다.
scope: Namespace
apiGroup: k8s.example.com
content/ko/docs/concepts/services-networking/network-policies.md
+2 -37
View File
@@ -45,42 +45,7 @@ pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glo
네트워크폴리시 의 예시는 다음과 같다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
```
{{< codenew file="service/networking/networkpolicy.yaml" >}}
{{< note >}}
선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다.
@@ -281,7 +246,7 @@ API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을
## 이름으로 네임스페이스 지정
{{< feature-state state="beta" for_k8s_version="1.21" >}}
{{< feature-state for_k8s_version="1.22" state="stable" >}}
쿠버네티스 컨트롤 플레인은 `NamespaceDefaultLabelName`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우
content/ko/docs/concepts/services-networking/service.md
+75 -28
View File
@@ -24,7 +24,7 @@ weight: 10
## 동기
쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 상태와
쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 목표 상태(desired state)와
일치하도록 생성되고 삭제된다. 파드는 비영구적 리소스이다.
만약 앱을 실행하기 위해 {{< glossary_tooltip term_id="deployment" text="디플로이먼트" >}}를 사용한다면,
동적으로 파드를 생성하고 제거할 수 있다.
@@ -108,13 +108,46 @@ spec:
필드와 같은 값으로 설정된다.
{{< /note >}}
파드의 포트 정의에는 이름이 있고, 서비스의 `targetPort` 속성에서 이 이름을
참조할 수 있다. 이것은 다른 포트 번호를 통한 가용한 동일 네트워크 프로토콜이 있고,
단일 구성 이름을 사용하는 서비스 내에
혼합된 파드가 존재해도 가능하다.
이를 통해 서비스를 배포하고 진전시키는데 많은 유연성을 제공한다.
예를 들어, 클라이언트를 망가뜨리지 않고, 백엔드 소프트웨어의 다음
버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
파드의 포트 정의에 이름이 있으므로,
서비스의 `targetPort` 속성에서 이 이름을 참조할 수 있다.
예를 들어, 다음과 같은 방법으로 서비스의 `targetPort`를 파드 포트에 바인딩할 수 있다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app.kubernetes.io/name: proxy
spec:
containers:
- name: nginx
image: nginx:11.14.2
ports:
- containerPort: 80
name: http-web-svc
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app.kubernetes.io/name: proxy
ports:
- name: name-of-service-port
protocol: TCP
port: 80
targetPort: http-web-svc
```
이것은 서로 다른 포트 번호를 통해 가용한 동일 네트워크 프로토콜이 있고,
단일 구성 이름을 사용하는 서비스 내에 혼합된 파드가 존재해도 가능하다.
이를 통해 서비스를 배포하고 진전시키는 데 많은 유연성을 제공한다.
예를 들어, 클라이언트를 망가뜨리지 않고,
백엔드 소프트웨어의 다음 버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
서비스의 기본 프로토콜은 TCP이다. 다른
[지원되는 프로토콜](#protocol-support)을 사용할 수도 있다.
@@ -125,9 +158,9 @@ spec:
### 셀렉터가 없는 서비스
서비스는 일반적으로 쿠버네티스 파드에 대한 접근을 추상화하지만,
다른 종류의 백엔드를 추상화할 수도 있다.
예를 들면
서비스는 일반적으로 셀렉터를 이용하여 쿠버네티스 파드에 대한 접근을 추상화하지만,
셀렉터 대신 매칭되는(corresponding) 엔드포인트와 함께 사용되면 다른 종류의 백엔드도 추상화할 수 있으며,
여기에는 클러스터 외부에서 실행되는 것도 포함된다. 예시는 다음과 같다.
* 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만,
테스트 환경에서는 자체 데이터베이스를 사용한다.
@@ -668,44 +701,38 @@ status:
#### 프로토콜 유형이 혼합된 로드밸런서
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
{{< feature-state for_k8s_version="v1.24" state="beta" >}}
기본적으로 로드밸런서 서비스 유형의 경우 둘 이상의 포트가 정의되어 있을 때 모든
포트는 동일한 프로토콜을 가져야 하며 프로토콜은 클라우드 공급자가
지원하는 프로토콜이어야 한다.
kube-apiserver에 대해 기능 게이트 `MixedProtocolLBService`가 활성화된 경우 둘 이상의 포트가 정의되어 있을 때 다른 프로토콜을 사용할 수 있다.
`MixedProtocolLBService` 기능 게이트(v1.24에서 kube-apiserver에 대해 기본적으로 활성화되어 있음)는
둘 이상의 포트가 정의되어 있는 경우에 로드밸런서 타입의 서비스에 대해 서로 다른 프로토콜을 사용할 수 있도록 해 준다.
{{< note >}}
로드밸런서 서비스 유형에 사용할 수 있는 프로토콜 세트는 여전히 클라우드 제공 업체에서 정의한다.
클라우드 제공자가 혼합 프로토콜을 지원하지 않는다면 이는 단일 프로토콜만을 제공한다는 것을 의미한다.
{{< /note >}}
#### 로드밸런서 NodePort 할당 비활성화
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
`type=LoadBalancer` 서비스에 대한 노드 포트 할당을 선택적으로 비활성화할 수 있으며,
이는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정하면 된다.
노드 포트를 사용하지 않고 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당할 것이다.
노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우
해당 노드 포트는 자동으로 할당 해제되지 **않는다**.
노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 해당 노드 포트는 자동으로 할당 해제되지 **않는다**.
이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다.
이 필드를 사용하려면 클러스터에 `ServiceLBNodePortControl`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있으므로,
`spec.allocateLoadBalancerNodePorts` 필드를 사용할 수 있다.
다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
#### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다.
이 필드를 사용하기 위해서는 클러스터에 `ServiceLoadBalancerClass` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있다. 다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
기본적으로, `spec.loadBalancerClass` 는 `nil` 이고,
클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면
`LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
@@ -1211,7 +1238,7 @@ VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일
충분해야 한다. 그러나, 이해가 필요한 부분 뒤에는
많은 일이 있다.
### 충돌 방지
### 충돌 방지 {#avoiding-collisions}
쿠버네티스의 주요 철학 중 하나는 잘못한 것이
없는 경우 실패할 수 있는 상황에 노출되어서는
@@ -1219,9 +1246,10 @@ VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일
충돌할 경우에 대비해 자신의 포트 번호를 선택하지
않아도 된다. 그것은 격리 실패이다.
서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, 두 개의
서비스가 충돌하지 않도록 해야 한다. 쿠버네티스는 각 서비스에 고유한 IP 주소를
할당하여 이를 수행한다.
서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해,
두 개의 서비스가 충돌하지 않도록 해야 한다.
쿠버네티스는 API 서버에 설정되어 있는 `service-cluster-ip-range` CIDR 범위에서
각 서비스에 고유한 IP 주소를 할당하여 이를 달성한다.
각 서비스가 고유한 IP를 받도록 하기 위해, 내부 할당기는
각 서비스를 만들기 전에 {{< glossary_tooltip term_id="etcd" >}}에서
@@ -1235,6 +1263,25 @@ IP 주소를 할당할 수 없다는 메시지와 함께 생성에 실패한다.
할당 (예: 관리자 개입으로)을 체크하고 더 이상 서비스에서 사용하지 않는 할당된
IP 주소를 정리한다.
#### `type: ClusterIP` 서비스의 IP 주소 범위 {#service-ip-static-sub-range}
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
그러나, 이러한 `ClusterIP` 할당 전략에는 한 가지 문제가 있는데,
그것은 사용자 또한 [서비스의 IP 주소를 직접 고를 수 있기 때문이다](#choosing-your-own-ip-address).
이로 인해 만약 내부 할당기(allocator)가 다른 서비스에 대해 동일한 IP 주소를 선택하면
충돌이 발생할 수 있다.
`ServiceIPStaticSubrange`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면,
할당 전략은 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진
`service-cluster-ip-range`의 크기에 기반하여 `ClusterIP` 범위를 두 대역으로 나누며,
여기서 이 공식은 _16 이상 256 이하이며, 그 사이에 계단 함수가 있음_ 으로 설명할 수 있다.
동적 IP 할당은 상위 대역에서 우선적으로 선택하며,
이를 통해 하위 대역에서 할당된 IP와의 충돌 위험을 줄인다.
이렇게 함으로써 사용자가 서비스의 고정 IP를
`service-cluster-ip-range`의 하위 대역에서 할당하면서도
충돌 위험을 줄일 수 있다.
### 서비스 IP 주소 {#ips-and-vips}
실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리,
content/ko/docs/concepts/services-networking/topology-aware-hints.md
+6
View File
@@ -19,6 +19,12 @@ _토폴로지 인지 힌트(Topology Aware Hints)_ 는 클라이언트가 엔드
예를 들어, 비용을 줄이거나 네트워크 성능을 높이기 위해,
인접성을 고려하여 트래픽을 라우트할 수 있다.
{{< note >}}
"토폴로지 인지 힌트" 기능은 베타 단계이며 기본적으로 활성화되어 있지 **않다**.
이 기능을 사용해 보려면,
`TopologyAwareHints` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
{{< /note >}}
<!-- body -->
## 동기(motivation)