Merge pull request #26613 from kubernetes/dev-1.20-ko.4
ko: Fourth Korean l10n work for release-1.20
This commit is contained in:
Kubernetes Prow Robot
@@ -1,9 +1,5 @@
|
||||
---
|
||||
title: 쿠버네티스 컨트롤 플레인에 대한 메트릭
|
||||
|
||||
|
||||
|
||||
|
||||
title: 쿠버네티스 시스템 컴포넌트에 대한 메트릭
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
@@ -12,7 +8,7 @@ weight: 60
|
||||
|
||||
시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다.
|
||||
|
||||
쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다.
|
||||
쿠버네티스 컴포넌트의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다.
|
||||
이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다.
|
||||
|
||||
<!-- body -->
|
||||
@@ -36,7 +32,7 @@ weight: 60
|
||||
|
||||
클러스터가 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}을 사용하는 경우, 메트릭을 읽으려면 `/metrics` 에 접근을 허용하는 클러스터롤(ClusterRole)을 가지는 사용자, 그룹 또는 서비스어카운트(ServiceAccount)를 통한 권한이 필요하다.
|
||||
예를 들면, 다음과 같다.
|
||||
```
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
@@ -156,5 +152,4 @@ kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/k
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다
|
||||
* [안정적인 쿠버네티스 메트릭](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) 목록을 참고한다
|
||||
* [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다
|
||||
|
||||
@@ -22,6 +22,16 @@ weight: 30
|
||||
명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도
|
||||
일부 시크릿을 만들 수 있다.
|
||||
|
||||
{{< caution >}}
|
||||
쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
|
||||
기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에
|
||||
액세스할 수 있는 모든 사용자가 일반 텍스트로 검색 할 수 있다.
|
||||
시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
|
||||
|
||||
1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
|
||||
2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
|
||||
{{< /caution >}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 시크릿 개요
|
||||
@@ -269,6 +279,13 @@ SSH 인증 시크릿 타입은 사용자 편의만을 위해서 제공된다.
|
||||
API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지
|
||||
검증도 한다.
|
||||
|
||||
{{< caution >}}
|
||||
SSH 개인 키는 자체적으로 SSH 클라이언트와 호스트 서버간에 신뢰할 수있는 통신을
|
||||
설정하지 않는다. ConfigMap에 추가된 `known_hosts` 파일과 같은
|
||||
"중간자(man in the middle)" 공격을 완화하려면 신뢰를 설정하는
|
||||
2차 수단이 필요하다.
|
||||
{{< /caution >}}
|
||||
|
||||
### TLS 시크릿
|
||||
|
||||
쿠버네티스는 보통 TLS를 위해 사용되는 인증서와 관련된 키를 저장하기 위해서
|
||||
@@ -786,7 +803,6 @@ immutable: true
|
||||
|
||||
수동으로 생성된 시크릿(예: GitHub 계정에 접근하기 위한 토큰이 포함된 시크릿)은
|
||||
시크릿의 서비스 어카운트를 기반한 파드에 자동으로 연결될 수 있다.
|
||||
해당 프로세스에 대한 자세한 설명은 [파드프리셋(PodPreset)을 사용하여 파드에 정보 주입하기](/docs/tasks/inject-data-application/podpreset/)를 참고한다.
|
||||
|
||||
## 상세 내용
|
||||
|
||||
@@ -1233,3 +1249,4 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
|
||||
- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
|
||||
- [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
|
||||
- [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
|
||||
|
||||
|
||||
@@ -54,7 +54,7 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
|
||||
|
||||
컨테이너 라이프사이클 관리 훅이 호출되면,
|
||||
쿠버네티스 관리 시스템은 훅 동작에 따라 핸들러를 실행하고,
|
||||
`exec` 와 `tcpSocket` 은 컨테이너에서 실행되고, `httpGet` 은 kubelet 프로세스에 의해 실행된다.
|
||||
`httpGet` 와 `tcpSocket` 은 kubelet 프로세스에 의해 실행되고, `exec` 은 컨테이너에서 실행된다.
|
||||
|
||||
훅 핸들러 호출은 해당 컨테이너를 포함하고 있는 파드의 컨텍스트와 동기적으로 동작한다.
|
||||
이것은 `PostStart` 훅에 대해서,
|
||||
|
||||
@@ -1,7 +1,4 @@
|
||||
---
|
||||
|
||||
|
||||
|
||||
title: 런타임클래스(RuntimeClass)
|
||||
content_type: concept
|
||||
weight: 20
|
||||
@@ -35,10 +32,6 @@ weight: 20
|
||||
|
||||
## 셋업
|
||||
|
||||
런타임클래스 기능 게이트가 활성화(기본값)된 것을 확인한다.
|
||||
기능 게이트 활성화에 대한 설명은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
참고한다. `RuntimeClass` 기능 게이트는 API 서버 _및_ kubelets에서 활성화되어야 한다.
|
||||
|
||||
1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서).
|
||||
2. 상응하는 런타임클래스 리소스 생성.
|
||||
|
||||
@@ -144,11 +137,9 @@ https://github.com/containerd/cri/blob/master/docs/config.md
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
|
||||
|
||||
쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터
|
||||
지원을 포함한다. 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는
|
||||
노드로 스케줄된다는 것을 보장할 수 있다. 이 스케줄링 기능을 사용하려면,
|
||||
[런타임 클래스 어드미션(admission) 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)를
|
||||
활성화(1.16 부터 기본값)해야 한다.
|
||||
RuntimeClass에 `scheduling` 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가
|
||||
이를 지원하는 노드로 예약되도록 제약 조건을 설정할 수 있다.
|
||||
`scheduling`이 설정되지 않은 경우 이 RuntimeClass는 모든 노드에서 지원되는 것으로 간주된다.
|
||||
|
||||
파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면,
|
||||
해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다.
|
||||
|
||||
@@ -69,7 +69,7 @@ weight: 10
|
||||
웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
|
||||
*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
|
||||
바이너리 플러그인은 kubelet(예:
|
||||
[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과
|
||||
[Flex 볼륨 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과
|
||||
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
|
||||
kubectl에서
|
||||
사용한다.
|
||||
@@ -157,7 +157,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
|
||||
|
||||
### 스토리지 플러그인
|
||||
|
||||
[Flex Volumes](/ko/docs/concepts/storage/volumes/#flexvolume)을 사용하면
|
||||
[Flex 볼륨](/ko/docs/concepts/storage/volumes/#flexvolume)을 사용하면
|
||||
Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써
|
||||
빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다.
|
||||
|
||||
|
||||
@@ -9,11 +9,11 @@ weight: 40
|
||||
|
||||
인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다.
|
||||
|
||||
kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는
|
||||
`kube-controller-manager` 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는
|
||||
클러스터와 함께 자동으로 실행되지 않는다.
|
||||
클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.
|
||||
|
||||
프로젝트로써 쿠버네티스는 [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme)와
|
||||
프로젝트로서 쿠버네티스는 [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme)와
|
||||
[nginx](https://git.k8s.io/ingress-nginx/README.md#readme) 인그레스 컨트롤러를 지원하고 유지한다.
|
||||
|
||||
|
||||
@@ -26,6 +26,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
|
||||
* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
|
||||
* [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) 기반의 인그레스 컨트롤러이다.
|
||||
* [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다.
|
||||
* [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
|
||||
Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
|
||||
@@ -42,7 +43,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
|
||||
기반 인그레스 컨트롤러다.
|
||||
* [쿠버네티스 용 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller#readme)는 [Kong 게이트웨이](https://konghq.com/kong/)를
|
||||
구동하는 인그레스 컨트롤러다.
|
||||
* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)는 [NGINX](https://www.nginx.com/resources/glossary)
|
||||
* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx-ingress-controller/)는 [NGINX](https://www.nginx.com/resources/glossary/nginx/)
|
||||
웹서버(프록시로 사용)와 함께 작동한다.
|
||||
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
|
||||
* [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
|
||||
|
||||
@@ -376,7 +376,7 @@ graph LR;
|
||||
트래픽을 일치 시킬 수 있다.
|
||||
|
||||
예를 들어, 다음 인그레스는 `first.bar.com`에 요청된 트래픽을
|
||||
`service1`로, `second.foo.com`는 `service2`로, 호스트 이름이 정의되지
|
||||
`service1`로, `second.bar.com`는 `service2`로, 호스트 이름이 정의되지
|
||||
않은(즉, 요청 헤더가 표시 되지 않는) IP 주소로의 모든
|
||||
트래픽은 `service3`로 라우팅 한다.
|
||||
|
||||
|
||||
@@ -134,7 +134,7 @@ spec:
|
||||
* 한 서비스에서 다른
|
||||
{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 또는 다른 클러스터의 서비스를 지정하려고 한다.
|
||||
* 워크로드를 쿠버네티스로 마이그레이션하고 있다. 해당 방식을 평가하는 동안,
|
||||
쿠버네티스에서는 일정 비율의 백엔드만 실행한다.
|
||||
쿠버네티스에서는 백엔드의 일부만 실행한다.
|
||||
|
||||
이러한 시나리오 중에서 파드 셀렉터 _없이_ 서비스를 정의 할 수 있다.
|
||||
예를 들면
|
||||
|
||||
@@ -13,7 +13,7 @@ weight: 50
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료되도록 한다.
|
||||
잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도한다.
|
||||
파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다. 지정된 수의
|
||||
성공 완료에 도달하면, 작업(즉, 잡)이 완료된다. 잡을 삭제하면 잡이 생성한
|
||||
파드가 정리된다.
|
||||
|
||||
@@ -76,4 +76,4 @@ TTL 컨트롤러는 쿠버네티스 리소스에
|
||||
|
||||
* [자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리)
|
||||
|
||||
* [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
|
||||
* [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md)
|
||||
|
||||
Reference in New Issue
Block a user