Merge pull request #25282 from kubernetes/dev-1.19-ko.5
Fifth Korean l10n work for release-1.19
This commit is contained in:
Kubernetes Prow Robot
@@ -96,7 +96,17 @@ weight: 30
|
||||
컨트롤러가 있다.
|
||||
[클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 본다.)
|
||||
|
||||
## 원하는 상태와 현재 상태 {#desired-vs-current}
|
||||
여기서 중요한 점은 컨트롤러가 의도한 상태를 가져오기 위해 약간의 변화를 주고,
|
||||
현재 상태를 클러스터의 API 서버에 다시 보고한다는 것이다.
|
||||
다른 컨트롤 루프는 보고된 데이터를 관찰하고 자체 조치를 할 수 있다.
|
||||
|
||||
온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가
|
||||
서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는
|
||||
[쿠버네티스 확장](/ko/docs/concepts/extend-kubernetes/)을 통해
|
||||
IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자 APIS 및
|
||||
기타 서비스 등과 간접적으로 연동하여 이를 구현한다.
|
||||
|
||||
## 의도한 상태와 현재 상태 {#desired-vs-current}
|
||||
|
||||
쿠버네티스는 클라우드-네이티브 관점에서 시스템을 관찰하며, 지속적인
|
||||
변화에 대응할 수 있다.
|
||||
|
||||
@@ -47,7 +47,7 @@ no_list: true
|
||||
|
||||
* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
|
||||
|
||||
* [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다.
|
||||
* [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)는 쿠버네티스가 자체 API에 대한 접근 제어를 구현하는 방법을 설명한다.
|
||||
|
||||
* [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다.
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ weight: 60
|
||||
이 섹션에서는, 쿠버네티스에서 표준 출력 스트림으로 데이터를
|
||||
출력하는 기본 로깅의 예시를 볼 수 있다. 이 데모에서는
|
||||
일부 텍스트를 초당 한 번씩 표준 출력에 쓰는 컨테이너와 함께
|
||||
[파드 명세](/examples/debug/counter-pod.yaml)를 사용한다.
|
||||
파드 명세를 사용한다.
|
||||
|
||||
{{< codenew file="debug/counter-pod.yaml" >}}
|
||||
|
||||
|
||||
@@ -122,6 +122,10 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht
|
||||
|
||||
가트너는 최신의 [매직 쿼드런트(Magic Quadrant)](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html)에서 BCF를 비저너리(Visionary)로 인정했다. BCF 쿠버네티스 온-프레미스 디플로이먼트 중 하나(지리적으로 다른 리전에 걸쳐 여러 DC에서 실행되는 쿠버네티스, DC/OS 및 VMware 포함)도 [여기](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)에서 사례로 참조된다.
|
||||
|
||||
### 캘리코
|
||||
|
||||
[캘리코](https://docs.projectcalico.org/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다.
|
||||
|
||||
### 실리움(Cilium)
|
||||
|
||||
[실리움](https://github.com/cilium/cilium)은 애플리케이션 컨테이너 간에
|
||||
@@ -289,14 +293,6 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
|
||||
[ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)에
|
||||
특정 쿠버네티스 플러그인 및 문서가 있다.
|
||||
|
||||
### 프로젝트 캘리코
|
||||
|
||||
[프로젝트 캘리코](https://docs.projectcalico.org/)는 오픈소스 컨테이너 네트워킹 공급자 및 네트워크 정책 엔진이다.
|
||||
|
||||
캘리코는 리눅스(오픈소스)와 윈도우(독점 - [Tigera](https://www.tigera.io/essentials/)에서 사용 가능) 모두에서 인터넷과 동일한 IP 네트워킹 원칙을 기반으로 쿠버네티스 파드를 연결하기 위한 확장성이 뛰어난 네트워킹 및 네트워크 정책 솔루션을 제공한다. 캘리코는 캡슐화나 오버레이 없이 구축되어 고성능의 대규모 데이터센터 네트워킹을 제공할 수 있다. 또한 캘리코는 분산 방화벽을 통해 쿠버네티스 파드에 대해 세분화된 의도기반의 네트워크 보안 정책을 제공한다.
|
||||
|
||||
캘리코는 플라넬, 일명 [canal](https://github.com/tigera/canal) 또는 네이티브 GCE, AWS나 Azure 네트워킹과 같은 다른 네트워킹 솔루션과 함께 정책 적용 모드로 실행될 수도 있다.
|
||||
|
||||
### 로마나
|
||||
|
||||
[로마나](https://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다.
|
||||
|
||||
@@ -97,6 +97,14 @@ some_counter 0
|
||||
|
||||
릴리스 `1.12` 에서 `1.13` 으로 업그레이드 중이지만, `1.12` 에서 사용 중단된 메트릭 `A` 를 사용하고 있다면, 커맨드 라인에서 `--show-hidden-metrics=1.12` 플래그로 히든 메트릭을 설정해야 하고, `1.14` 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다.
|
||||
|
||||
## 액셀러레이터 메트릭 비활성화
|
||||
|
||||
kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. NVIDIA GPU와 같은 액셀러레이터의 경우, 이러한 메트릭을 수집하기 위해 kubelet은 드라이버에 열린 핸들을 가진다. 이는 인프라 변경(예: 드라이버 업데이트)을 수행하기 위해 클러스터 관리자가 kubelet 에이전트를 중지해야 함을 의미한다.
|
||||
|
||||
액셀러레이터 메트릭을 수집하는 책임은 이제 kubelet이 아닌 공급 업체에 있다. 공급 업체는 메트릭을 수집하여 메트릭 서비스(예: 프로메테우스)에 노출할 컨테이너를 제공해야 한다.
|
||||
|
||||
[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트:~:text= DisableAcceleratorUsageMetrics,-false)는 [이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를 사용하여 kubelet에서 수집한 메트릭을 비활성화한다.
|
||||
|
||||
## 컴포넌트 메트릭
|
||||
|
||||
### kube-controller-manager 메트릭
|
||||
|
||||
@@ -12,51 +12,380 @@ weight: 30
|
||||
|
||||
쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은
|
||||
민감한 정보를 저장하고 관리할 수 있다. 기밀 정보를 시크릿에 저장하는 것이
|
||||
{{< glossary_tooltip term_id="pod" text="파드" >}} 정의나
|
||||
{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}} 내에 그대로 두는 것보다 안전하고 유연하다. 자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다.
|
||||
|
||||
{{< glossary_tooltip term_id="pod" >}} 정의나
|
||||
{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}
|
||||
내에 그대로 두는 것보다 안전하고 유연하다.
|
||||
자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다.
|
||||
|
||||
시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를
|
||||
포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가 파드
|
||||
명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도
|
||||
일부 시크릿을 만들 수 있다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 시크릿 개요
|
||||
|
||||
시크릿은 비밀번호, 토큰 또는 키와 같은 소량의
|
||||
민감한 데이터를 포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가
|
||||
파드 명세 또는 이미지에 포함될 수 있다. 사용자는 시크릿을 생성할 수 있으며 시스템도
|
||||
일부 시크릿을 생성한다.
|
||||
|
||||
시크릿을 사용하려면, 파드가 시크릿을 참조해야 한다.
|
||||
시크릿은 세 가지 방법으로 파드와 함께 사용할 수 있다.
|
||||
|
||||
- 하나 이상의 컨테이너에 마운트된
|
||||
{{< glossary_tooltip text="볼륨" term_id="volume" >}} 내의
|
||||
[파일](#시크릿을-파드의-파일로-사용하기)로써 사용.
|
||||
{{< glossary_tooltip text="볼륨" term_id="volume" >}} 내의
|
||||
[파일](#시크릿을-파드의-파일로-사용하기)로써 사용.
|
||||
- [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
|
||||
- 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
|
||||
|
||||
시크릿 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.
|
||||
사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를
|
||||
명시할 수 있다. 해당 `data` 와 `stringData` 필드는 선택적으로 명시할 수 있다.
|
||||
`data` 필드의 모든 키(key)에 해당하는 값(value)은 base64로 인코딩된 문자열이어야 한다.
|
||||
만약 사용자에게 base64로의 문자열 변환이 적합하지 않다면,
|
||||
임의의 문자열을 값으로 받는 `stringData` 필드를 대신 사용할 수 있다.
|
||||
|
||||
`data` 와 `stringData` 의 키는 영숫자 및 `-`, `_` 또는 `.` 으로
|
||||
구성되어야 한다.
|
||||
`data` 및 `stringData`의 키는 영숫자 문자,
|
||||
`-`, `_`, 또는 `.` 으로 구성되어야 한다. `stringData` 필드의 모든 키-값 쌍은 의도적으로
|
||||
`data` 필드로 합쳐진다. 만약 키가 `data` 와 `stringData` 필드 모두에 정의되어
|
||||
있으면, `stringData` 필드에 지정된 값이
|
||||
우선적으로 사용된다.
|
||||
|
||||
### 빌트인 시크릿
|
||||
## 시크릿 타입 {#secret-types}
|
||||
|
||||
#### 서비스 어카운트는 API 자격 증명으로 시크릿을 자동으로 생성하고 연결함
|
||||
시크릿을 생성할 때, [`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
|
||||
리소스의 `type` 필드를 사용하거나, (활용 가능하다면) `kubectl` 의
|
||||
유사한 특정 커맨드라인 플래그를 사용하여 시크릿의 타입을 명시할 수 있다.
|
||||
시크릿 타입은 시크릿 데이터의 프로그래믹 처리를 촉진시키기 위해 사용된다.
|
||||
|
||||
쿠버네티스는 API 접근을 위한 자격 증명이 포함된
|
||||
시크릿을 자동으로 생성하고 이러한 유형의 시크릿을 사용하도록 파드를 자동으로
|
||||
수정한다.
|
||||
쿠버네티스는 일반적인 사용 시나리오를 위해 몇 가지 빌트인 타입을 제공한다.
|
||||
이 타입은 쿠버네티스가 부과하여 수행되는 검증 및 제약에
|
||||
따라 달라진다.
|
||||
|
||||
원하는 경우 API 자격 증명의 자동 생성 및 사용을 비활성화하거나
|
||||
오버라이드할 수 있다. 그러나, API 서버에 안전하게 접근하기만 하면 되는 경우,
|
||||
자동 생성 및 사용이 권장되는 워크플로이다.
|
||||
| 빌트인 타입 | 사용처 |
|
||||
|--------------|-------|
|
||||
| `Opaque` | 임의의 사용자 정의 데이터 |
|
||||
| `kubernetes.io/service-account-token` | 서비스 어카운트 토큰 |
|
||||
| `kubernetes.io/dockercfg` | 직렬화 된(serialized) `~/.dockercfg` 파일 |
|
||||
| `kubernetes.io/dockerconfigjson` | 직렬화 된 `~/.docker/config.json` 파일 |
|
||||
| `kubernetes.io/basic-auth` | 기본 인증을 위한 자격 증명(credential) |
|
||||
| `kubernetes.io/ssh-auth` | SSH를 위한 자격 증명 |
|
||||
| `kubernetes.io/tls` | TLS 클라이언트나 서버를 위한 데이터 |
|
||||
| `bootstrap.kubernetes.io/token` | 부트스트랩 토큰 데이터 |
|
||||
|
||||
서비스 어카운트 작동 방식에 대한 자세한 내용은
|
||||
[서비스어카운트(ServiceAccount)](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 참고한다.
|
||||
사용자는 시크릿 오브젝트의 `type` 값에 비어 있지 않은 문자열을 할당하여 자신만의 시크릿
|
||||
타입을 정의하고 사용할 수 있다. 비어 있는 문자열은 `Opaque` 타입으로 인식된다.
|
||||
쿠버네티스는 타입 명칭에 제약을 부과하지는 않는다. 그러나 만약
|
||||
빌트인 타입 중 하나를 사용한다면, 해당 타입에 정의된 모든 요구 사항을
|
||||
만족시켜야 한다.
|
||||
|
||||
### 시크릿 생성하기
|
||||
### 불투명(Opaque) 시크릿
|
||||
|
||||
`Opaque` 은 시크릿 구성 파일에서 누락된 경우의 기본 시크릿 타입이다.
|
||||
`kubectl` 을 사용하여 시크릿을 생성할 때 `Opaque` 시크릿 타입을 나타내기
|
||||
위해서는 `generic` 하위 커맨드를 사용할 것이다. 예를 들어, 다음 커맨드는
|
||||
타입 `Opaque` 의 비어 있는 시크릿을 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic empty-secret
|
||||
kubectl get secret empty-secret
|
||||
```
|
||||
|
||||
출력은 다음과 같다.
|
||||
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
empty-secret Opaque 0 2m6s
|
||||
```
|
||||
|
||||
해당 `DATA` 열은 시크릿에 저장된 데이터 아이템의 수를 보여준다.
|
||||
이 경우, `0` 은 비어 있는 시크릿을 방금 하나 생성하였다는 것을 의미한다.
|
||||
|
||||
### 서비스 어카운트 토큰 시크릿
|
||||
|
||||
`kubernetes.io/service-account-token` 시크릿 타입은 서비스 어카운트를 확인하는 토큰을 저장하기 위해서 사용한다. 이 시크릿 타입을 사용할 때는,
|
||||
`kubernetes.io/service-account.name` 어노테이션이 존재하는 서비스
|
||||
어카운트 이름으로 설정되도록 해야 한다. 쿠버네티스 컨트롤러는
|
||||
`kubernetes.io/service-account.uid` 및 실제 토큰
|
||||
콘텐츠로 설정된 `data` 필드의 `token` 키와 같은,
|
||||
몇 가지 다른 필드들을 채운다.
|
||||
|
||||
다음은 서비스 어카운트 토큰 시크릿의 구성 예시이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-sa-sample
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: "sa-name"
|
||||
type: kubernetes.io/service-account-token
|
||||
data:
|
||||
# 사용자는 불투명 시크릿을 사용하므로 추가적인 키 값 쌍을 포함할 수 있다.
|
||||
extra: YmFyCg==
|
||||
```
|
||||
|
||||
`Pod` 를 생성할 때, 쿠버네티스는 자동으로 서비스 어카운트 시크릿을
|
||||
생성하고 자동으로 파드가 해당 시크릿을 사용하도록 수정한다. 해당 서비스
|
||||
어카운트 토큰 시크릿은 API 접속을 위한 자격 증명을 포함한다.
|
||||
|
||||
이러한 API 자격 증명의 자동 생성과 사용은 원하는 경우 해제하거나
|
||||
기각할 수 있다. 그러나 만약 사용자가 API 서버에 안전하게 접근하는 것만
|
||||
필요하다면, 이것이 권장되는 워크플로우이다.
|
||||
|
||||
[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 보면
|
||||
서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다.
|
||||
또한 파드에서 서비스 어카운트를 참조하는 방법을
|
||||
[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)의
|
||||
`automountServiceAccountToken` 필드와 `serviceAccountName`
|
||||
필드를 통해 확인할 수 있다.
|
||||
|
||||
### 도커 컨피그 시크릿
|
||||
|
||||
이미지에 대한 도커 레지스트리 접속 자격 증명을 저장하기 위한
|
||||
시크릿을 생성하기 위해서 다음의 `type` 값 중 하나를 사용할 수 있다.
|
||||
|
||||
- `kubernetes.io/dockercfg`
|
||||
- `kubernetes.io/dockerconfigjson`
|
||||
|
||||
`kubernetes.io/dockercfg` 는 직렬화 된 도커 커맨드라인 구성을
|
||||
위한 기존(legacy) 포맷 `~/.dockercfg` 를 저장하기 위해 할당된 타입이다.
|
||||
시크릿 타입을 사용할 때는, `data` 필드가 base64 포맷으로
|
||||
인코딩된 `~/.dockercfg` 파일의 콘텐츠를 값으로 가지는 `.dockercfg` 키를 포함하고 있는지
|
||||
확실히 확인해야 한다.
|
||||
|
||||
`kubernetes/dockerconfigjson` 타입은 `~/.dockercfg` 의
|
||||
새로운 포맷인 `~/.docker/config.json` 파일과 동일한 포맷 법칙을
|
||||
따르는 직렬화 된 JSON의 저장을 위해 디자인되었다.
|
||||
이 시크릿 타입을 사용할 때는, 시크릿 오브젝트의 `data` 필드가 `.dockerconfigjson` 키를
|
||||
꼭 포함해야 한다. `~/.docker/config.json` 파일을 위한 콘텐츠는
|
||||
base64로 인코딩된 문자열으로 제공되어야 한다.
|
||||
|
||||
아래는 시크릿의 `kubernetes.io/dockercfg` 타입 예시이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-dockercfg
|
||||
type: kubernetes.io/dockercfg
|
||||
data:
|
||||
.dockercfg: |
|
||||
"<base64 encoded ~/.dockercfg file>"
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
만약 base64 인코딩 수행을 원하지 않는다면, 그 대신 `stringData` 필드의
|
||||
사용을 선택할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
이러한 타입들을 매니페스트를 사용하여 생성하는 경우, API
|
||||
서버는 해당 `data` 필드에 기대하는 키가 존재하는지 확인하고,
|
||||
제공된 값이 유효한 JSON으로 파싱될 수 있는지 검증한다. API
|
||||
서버가 해당 JSON이 실제 도커 컨피그 파일인지를 검증하지는 않는다.
|
||||
|
||||
도커 컨피그 파일을 가지고 있지 않거나 도커 레지스트리 시크릿을 생성하기
|
||||
위해 `kubectl` 을 사용하고 싶은 경우, 다음과 같이 처리할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl create secret docker-registry secret-tiger-docker \
|
||||
--docker-username=tiger \
|
||||
--docker-password=pass113 \
|
||||
--docker-email=tiger@acme.com
|
||||
```
|
||||
|
||||
이 커맨드는 `kubernetes.io/dockerconfigjson` 타입의 시크릿을 생성한다.
|
||||
만약 `data` 필드로부터 `.dockerconfigjson` 콘텐츠를 복사(dump)해오면,
|
||||
다음과 같이 유효한 도커 JSON 콘텐츠를
|
||||
즉석에서 얻게 될 것이다.
|
||||
|
||||
```json
|
||||
{
|
||||
"auths": {
|
||||
"https://index.docker.io/v1/": {
|
||||
"username": "tiger",
|
||||
"password": "pass113",
|
||||
"email": "tiger@acme.com",
|
||||
"auth": "dGlnZXI6cGFzczExMw=="
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 기본 인증 시크릿
|
||||
|
||||
`kubernetes.io/basic-auth` 타입은 기본 인증을 위한 자격 증명을 저장하기
|
||||
위해 제공된다. 이 시크릿 타입을 사용할 때는 시크릿의 `data` 필드가
|
||||
다음의 두 키를 포함해야 한다.
|
||||
|
||||
- `username`: 인증을 위한 사용자 이름
|
||||
- `password`: 인증을 위한 암호나 토큰
|
||||
|
||||
위의 두 키에 대한 두 값은 모두 base64로 인코딩된 문자열이다. 물론,
|
||||
시크릿 생성 시 `stringData` 를 사용하여 평문 텍스트 콘텐츠(clear text content)를 제공할
|
||||
수도 있다.
|
||||
|
||||
다음의 YAML은 기본 인증 시크릿을 위한 구성 예시이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-basic-auth
|
||||
type: kubernetes.io/basic-auth
|
||||
stringData:
|
||||
username: admin
|
||||
password: t0p-Secret
|
||||
```
|
||||
|
||||
이 기본 인증 시크릿 타입은 사용자 편의만을 위해서 제공된다.
|
||||
사용자는 기본 인증에서 사용되는 자격 증명을 위한 `Opaque` 를 생성할 수도 있다.
|
||||
그러나, 빌트인 시크릿 타입을 사용하는 것은 사용자의 자격 증명들의 포맷을 통합하는 데 도움이 되고,
|
||||
API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지
|
||||
검증도 한다.
|
||||
|
||||
### SSH 인증 시크릿
|
||||
|
||||
이 빌트인 타입 `kubernetes.io/ssh-auth` 는 SSH 인증에 사용되는 데이터를
|
||||
저장하기 위해서 제공된다. 이 시크릿 타입을 사용할 때는 `ssh-privatekey`
|
||||
키-값 쌍을 사용할 SSH 자격 증명으로 `data` (또는 `stringData`)
|
||||
필드에 명시해야 할 것이다.
|
||||
|
||||
다음 YAML은 SSH 인증 시크릿의 구성 예시이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-ssh-auth
|
||||
type: kubernetes.io/ssh-auth
|
||||
data:
|
||||
# 본 예시를 위해 축약된 데이터임
|
||||
ssh-privatekey: |
|
||||
MIIEpQIBAAKCAQEAulqb/Y ...
|
||||
```
|
||||
|
||||
SSH 인증 시크릿 타입은 사용자 편의만을 위해서 제공된다.
|
||||
사용자는 SSH 인증에서 사용되는 자격 증명을 위한 `Opaque` 를 생성할 수도 있다.
|
||||
그러나, 빌트인 시크릿 타입을 사용하는 것은 사용자의 자격 증명들의 포맷을 통합하는 데 도움이 되고,
|
||||
API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지
|
||||
검증도 한다.
|
||||
|
||||
### TLS 시크릿
|
||||
|
||||
쿠버네티스는 보통 TLS를 위해 사용되는 인증서와 관련된 키를 저장하기 위해서
|
||||
빌트인 시크릿 타입 `kubernetes.io/tls` 를 제공한다.
|
||||
이 데이터는 인그레스 리소스의 TLS 종료에 주로 사용되지만, 다른
|
||||
리소스나 워크로드에 의해 직접적으로 사용될 수도 있다.
|
||||
이 타입의 시크릿을 사용할 때는 `tls.key` 와 `tls.crt` 키가 시크릿 구성의
|
||||
`data` (또는 `stringData`) 필드에서 제공되어야 한다. 그러나, API
|
||||
서버가 각 키에 대한 값이 유효한지 실제로 검증하지는 않는다.
|
||||
|
||||
다음 YAML은 TLS 시크릿을 위한 구성 예시를 포함한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-tls
|
||||
type: kubernetes.io/tls
|
||||
data:
|
||||
# 본 예시를 위해 축약된 데이터임
|
||||
tls.crt: |
|
||||
MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
|
||||
tls.key: |
|
||||
MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
|
||||
```
|
||||
|
||||
TLS 시크릿 타입은 사용자 편의만을 위해서 제공된다. 사용자는 TLS 서버 및/또는
|
||||
클라이언트를 위해 사용되는 자격 증명을 위한 `Opaque` 를 생성할 수도 있다. 그러나, 빌트인
|
||||
시크릿 타입을 사용하는 것은 사용자의 자격 증명들의 포맷을 통합하는 데 도움이 되고,
|
||||
API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지 검증도 한다.
|
||||
|
||||
`kubectl` 를 사용하여 TLS 시크릿을 생성할 때, `tls` 하위 커맨드를
|
||||
다음 예시와 같이 사용할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl create secret tls my-tls-secret \
|
||||
--cert=path/to/cert/file \
|
||||
--key=path/to/key/file
|
||||
```
|
||||
|
||||
공개/개인 키 쌍은 사전에 존재해야 한다. `--cert` 를 위한 공개 키 인증서는
|
||||
.PEM 으로 인코딩(Base64로 인코딩된 DER 포맷)되어야 하며, `--key` 를 위해 주어진
|
||||
개인 키에 맞아야 한다.
|
||||
개인 키는 일반적으로 PEM 개인 키 포맷이라고 하는,
|
||||
암호화되지 않은 형태(unencrypted)이어야 한다. 두 가지 방식 모두에 대해서, PEM의
|
||||
시작과 끝 라인(예를 들면, 인증서의 `--------BEGIN CERTIFICATE-----` 및 `-------END CERTIFICATE----`)
|
||||
은 포함되면 *안* 된다.
|
||||
|
||||
### 부트스트랩 토큰 시크릿
|
||||
|
||||
부트스트랩 토큰 시크릿은 시크릿 `type` 을 `bootstrap.kubernetes.io/token` 으로
|
||||
명확하게 지정하면 생성할 수 있다. 이 타입의 시크릿은 노드 부트스트랩 과정 중에 사용되는
|
||||
토큰을 위해 디자인되었다. 이것은 잘 알려진 컨피그맵에 서명하는 데 사용되는
|
||||
토큰을 저장한다.
|
||||
|
||||
부트스트랩 토큰 시크릿은 보통 `kube-system` 네임스페이스에 생성되며
|
||||
`<token-id>` 가 해당 토큰 ID의 6개 문자의 문자열으로 구성된 `bootstrap-token-<token-id>` 형태로
|
||||
이름이 지정된다.
|
||||
|
||||
쿠버네티스 매니페스트로서, 부트스트렙 토큰 시크릿은 다음과 유사할
|
||||
것이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: bootstrap-token-5emitj
|
||||
namespace: kube-system
|
||||
type: bootstrap.kubernetes.io/token
|
||||
data:
|
||||
auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4=
|
||||
expiration: MjAyMC0wOS0xM1QwNDozOToxMFo=
|
||||
token-id: NWVtaXRq
|
||||
token-secret: a3E0Z2lodnN6emduMXAwcg==
|
||||
usage-bootstrap-authentication: dHJ1ZQ==
|
||||
usage-bootstrap-signing: dHJ1ZQ==
|
||||
```
|
||||
|
||||
부트스트랩 타입은 `data` 아래 명시된 다음의 키들을 가진다.
|
||||
|
||||
- `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항.
|
||||
- `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항.
|
||||
- `description1`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
|
||||
문자열. 선택 사항.
|
||||
- `expiration`: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를
|
||||
사용하는 절대 UTC 시간. 선택 사항.
|
||||
- `usage-bootstrap-<usage>`: 부트스트랩 토큰의 추가적인 사용처를 나타내는
|
||||
불리언(boolean) 플래그.
|
||||
- `auth-extra-groups`: system:bootstrappers 그룹에 추가로 인증될
|
||||
쉼표로 구분된 그룹 이름 목록.
|
||||
|
||||
위의 YAML은 모두 base64로 인코딩된 문자열 값이므로 혼란스러워 보일
|
||||
수 있다. 사실은 다음 YAML을 사용하여 동일한 시크릿 오브젝트 결과를 만드는
|
||||
동일한 시크릿을 생성할 수 있다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
# 시크릿 이름이 어떻게 지정되었는지 확인
|
||||
name: bootstrap-token-5emitj
|
||||
# 부트스트랩 토큰 시크릿은 일반적으로 kube-system 네임스페이스에 포함
|
||||
namespace: kube-system
|
||||
type: bootstrap.kubernetes.io/token
|
||||
stringData:
|
||||
auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token"
|
||||
expiration: "2020-09-13T04:39:10Z"
|
||||
# 이 토큰 ID는 이름에 사용됨
|
||||
token-id: "5emitj"
|
||||
token-secret: "kq4gihvszzgn1p0r"
|
||||
# 이 토큰은 인증을 위해서 사용될 수 있음
|
||||
usage-bootstrap-authentication: "true"
|
||||
# 또한 서명(signing)에도 사용될 수 있음
|
||||
usage-bootstrap-signing: "true"
|
||||
```
|
||||
|
||||
## 시크릿 생성하기
|
||||
|
||||
시크릿을 생성하기 위한 몇 가지 옵션이 있다.
|
||||
|
||||
@@ -64,7 +393,7 @@ weight: 30
|
||||
- [구성 파일로 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- [kustomize를 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
|
||||
### 시크릿 편집하기
|
||||
## 시크릿 편집하기
|
||||
|
||||
기존 시크릿은 다음 명령을 사용하여 편집할 수 있다.
|
||||
|
||||
@@ -791,11 +1120,11 @@ spec:
|
||||
HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음, HMAC이 있는 일부 메시지에
|
||||
서명해야 하는 프로그램을 고려한다. 애플리케이션 로직이
|
||||
복잡하기 때문에, 서버에서 눈에 띄지 않는 원격 파일 읽기 공격이
|
||||
있을 수 있으며, 이로 인해 프라이빗 키가 공격자에게 노출될 수 있다.
|
||||
있을 수 있으며, 이로 인해 개인 키가 공격자에게 노출될 수 있다.
|
||||
|
||||
이는 두 개의 컨테이너의 두 개 프로세스로 나눌 수 있다. 사용자 상호 작용과
|
||||
비즈니스 로직을 처리하지만, 프라이빗 키를 볼 수 없는 프론트엔드 컨테이너와
|
||||
프라이빗 키를 볼 수 있고, 프론트엔드의 간단한 서명 요청(예를 들어, localhost 네트워킹을 통해)에
|
||||
비즈니스 로직을 처리하지만, 개인 키를 볼 수 없는 프론트엔드 컨테이너와
|
||||
개인 키를 볼 수 있고, 프론트엔드의 간단한 서명 요청(예를 들어, localhost 네트워킹을 통해)에
|
||||
응답하는 서명자 컨테이너로 나눌 수 있다.
|
||||
|
||||
이 분할된 접근 방식을 사용하면, 공격자는 이제 애플리케이션 서버를 속여서
|
||||
|
||||
@@ -61,9 +61,9 @@ weight: 10
|
||||
|
||||
`imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다.
|
||||
|
||||
## 매니페스트가 있는 다중 아키텍처 이미지
|
||||
## 이미지 인덱스가 있는 다중 아키텍처 이미지
|
||||
|
||||
바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 컨테이너 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 제공할 수도 있다. 매니페스트는 아키텍처별 버전의 컨테이너에 대한 이미지 매니페스트를 참조할 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다.
|
||||
바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 [컨테이너 이미지 인덱스](https://github.com/opencontainers/image-spec/blob/master/image-index.md)를 제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 가리킬 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다.
|
||||
|
||||
쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, 접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성 또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다.
|
||||
|
||||
|
||||
@@ -126,7 +126,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
|
||||
|
||||
### API 접근 익스텐션
|
||||
|
||||
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
|
||||
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다.
|
||||
|
||||
이러한 각 단계는 익스텐션 포인트를 제공한다.
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ weight: 10
|
||||
<!-- body -->
|
||||
## 커스텀 리소스
|
||||
|
||||
*리소스* 는 [쿠버네티스 API](/ko/docs/reference/using-api/api-overview/)에서 특정 종류의
|
||||
*리소스* 는 [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에서 특정 종류의
|
||||
[API 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 모음을 저장하는 엔드포인트이다. 예를 들어 빌트인 *파드* 리소스에는 파드 오브젝트 모음이 포함되어 있다.
|
||||
|
||||
*커스텀 리소스* 는 쿠버네티스 API의 익스텐션으로, 기본 쿠버네티스 설치에서 반드시
|
||||
|
||||
@@ -127,7 +127,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
|
||||
|
||||
### API 접근 익스텐션
|
||||
|
||||
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
|
||||
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다.
|
||||
|
||||
이러한 각 단계는 익스텐션 포인트를 제공한다.
|
||||
|
||||
|
||||
@@ -227,7 +227,7 @@ spec:
|
||||
|
||||
* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다.
|
||||
* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
|
||||
* [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 프로젝트 탐색
|
||||
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색
|
||||
* [svc-cat.io](https://svc-cat.io/docs/) 살펴보기
|
||||
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ card:
|
||||
|
||||
대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/)
|
||||
커맨드 라인 인터페이스 또는 API를 사용하는
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과
|
||||
[kubeadm](/ko/docs/reference/setup-tools/kubeadm/)과
|
||||
같은 다른 커맨드 라인 도구를 통해 수행할 수 있다.
|
||||
그러나, REST 호출을 사용하여 API에 직접 접근할 수도 있다.
|
||||
|
||||
@@ -101,8 +101,20 @@ API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를
|
||||
제어할 수 있도록 한다.
|
||||
|
||||
보다 쉽게 발전하고 API를 확장하기 위해, 쿠버네티스는
|
||||
[활성화 또는 비활성화](/ko/docs/reference/using-api/api-overview/#api-그룹-활성화-또는-비활성화-하기)가
|
||||
가능한 [API 그룹](/ko/docs/reference/using-api/api-overview/#api-그룹)을 구현한다.
|
||||
[활성화 또는 비활성화](/ko/docs/reference/using-api/#api-그룹-활성화-또는-비활성화)가
|
||||
가능한 [API 그룹](/ko/docs/reference/using-api/#api-그룹)을 구현한다.
|
||||
|
||||
API 리소스는 API 그룹, 리소스 유형, 네임스페이스
|
||||
(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는
|
||||
여러 API 버전을 통해 동일한 기본 데이터를 제공하고 API 버전 간의
|
||||
변환을 투명하게 처리할 수 있다. 이 모든 다른 버전은 실제로
|
||||
같은 리소스의 표현이다. 예를 들어 동일한 리소스에 대해
|
||||
두 가지 버전 `v1`과 `v1beta1`이 있다고 가정해 보자.
|
||||
`v1beta1` 버전에서 생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서
|
||||
읽기, 업데이트 및 삭제할 수 있다.
|
||||
|
||||
API 버전 수준 정의에 대한 자세한 내용은
|
||||
[API 버전 레퍼런스](/ko/docs/reference/using-api/#api-버전-규칙)를 참조한다.
|
||||
|
||||
API 리소스는 해당 API 그룹, 리소스 유형, 네임스페이스
|
||||
(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 여러 API 버전을 통해 동일한
|
||||
@@ -129,7 +141,7 @@ API 버전 수준 정의에 대한 자세한 내용은
|
||||
|
||||
- 자체 [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)을
|
||||
추가하여 쿠버네티스 API를 확장하는 방법에 대해 배우기.
|
||||
- [API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)는
|
||||
- [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access/)는
|
||||
클러스터가 API 접근을 위한 인증 및 권한을 관리하는 방법을 설명한다.
|
||||
- [API 레퍼런스](/docs/reference/kubernetes-api/)를
|
||||
읽고 API 엔드포인트, 리소스 유형 및 샘플에 대해 배우기.
|
||||
|
||||
@@ -35,7 +35,7 @@ sitemap:
|
||||
|
||||
각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다.
|
||||
|
||||
**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
|
||||
**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
|
||||
|
||||
컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다.
|
||||
|
||||
|
||||
@@ -91,6 +91,7 @@ deployment.apps/nginx-deployment created
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다.
|
||||
|
||||
* [파드](/ko/docs/concepts/workloads/pods/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
|
||||
* 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
|
||||
* API 개념의 더 많은 설명은 [쿠버네티스 API 사용](/ko/docs/reference/using-api/)을 본다.
|
||||
|
||||
@@ -185,7 +185,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'
|
||||
[`services`](/ko/docs/concepts/services-networking/service/) 와
|
||||
[`replicationcontrollers`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은
|
||||
일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서
|
||||
[파드](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다.
|
||||
[파드](/ko/docs/concepts/workloads/pods/)와 같은 다른 리소스 집합을 선택한다.
|
||||
|
||||
#### 서비스와 레플리케이션 컨트롤러
|
||||
|
||||
|
||||
@@ -138,12 +138,16 @@ RBAC 바인딩에 대한 자세한 예는,
|
||||
### 문제 해결
|
||||
|
||||
- [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)는
|
||||
[보안 API 포트](/ko/docs/reference/access-authn-authz/controlling-access/)에 대해 실행해야 하며,
|
||||
슈퍼유저 권한이 없어야 한다. 그렇지 않으면 요청이 인증 및 권한 부여 모듈을 우회하고,
|
||||
모든 파드시큐리티폴리시 오브젝트가 허용되며
|
||||
사용자는 특권있는 컨테이너를 만들 수 있다. 컨트롤러 관리자 권한 구성에 대한 자세한
|
||||
내용은 [컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을
|
||||
참고하길 바란다.
|
||||
보안 API 포트에 대해 실행되어야 하며 수퍼유저 권한이 없어야 한다.
|
||||
API 서버 접근 제어에 대한 자세한 내용은
|
||||
[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)를 참고하길 바란다.
|
||||
컨트롤러 관리자가 신뢰할 수 있는 API 포트(`localhost` 리스너라고도 함)를
|
||||
통해 연결된 경우, 요청이 인증 및 권한 부여 모듈을 우회하고,
|
||||
모든 파드시큐리티폴리시 오브젝트가 허용되며 사용자는 특권을 가진 컨테이너를
|
||||
만들 수 있는 권한을 부여할 수 있다.
|
||||
|
||||
컨트롤러 관리자 권한 구성에 대한 자세한 내용은
|
||||
[컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을 참고하기 바란다.
|
||||
|
||||
## 정책 순서
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ weight: 10
|
||||
|
||||
`ResourceQuota` 오브젝트로 정의된 리소스 쿼터는 네임스페이스별 총 리소스 사용을 제한하는
|
||||
제약 조건을 제공한다. 유형별로 네임스페이스에서 만들 수 있는 오브젝트 수와
|
||||
해당 프로젝트의 리소스가 사용할 수 있는 총 컴퓨트 리소스의 양을
|
||||
해당 네임스페이스의 리소스가 사용할 수 있는 총 컴퓨트 리소스의 양을
|
||||
제한할 수 있다.
|
||||
|
||||
리소스 쿼터는 다음과 같이 작동한다.
|
||||
@@ -23,10 +23,10 @@ weight: 10
|
||||
- 다른 팀은 다른 네임스페이스에서 작동한다. 현재 이것은 자발적이지만 ACL을 통해 이 필수 사항을
|
||||
적용하기 위한 지원이 계획되어 있다.
|
||||
|
||||
- 관리자는 각 네임스페이스에 대해 하나의 `ResourceQuota`를 생성한다.
|
||||
- 관리자는 각 네임스페이스에 대해 하나의 리소스쿼터를 생성한다.
|
||||
|
||||
- 사용자는 네임스페이스에서 리소스(파드, 서비스 등)를 생성하고 쿼터 시스템은
|
||||
사용량을 추적하여 `ResourceQuota`에 정의된 하드(hard) 리소스 제한을 초과하지 않도록 한다.
|
||||
사용량을 추적하여 리소스쿼터에 정의된 하드(hard) 리소스 제한을 초과하지 않도록 한다.
|
||||
|
||||
- 리소스를 생성하거나 업데이트할 때 쿼터 제약 조건을 위반하면 위반된 제약 조건을 설명하는
|
||||
메시지와 함께 HTTP 상태 코드 `403 FORBIDDEN`으로 요청이 실패한다.
|
||||
@@ -38,7 +38,7 @@ weight: 10
|
||||
이 문제를 회피하는 방법에 대한 예제는
|
||||
[연습](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)을 참고하길 바란다.
|
||||
|
||||
`ResourceQuota` 오브젝트의 이름은 유효한
|
||||
리소스쿼터 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다.
|
||||
|
||||
네임스페이스와 쿼터를 사용하여 만들 수 있는 정책의 예는 다음과 같다.
|
||||
@@ -59,7 +59,7 @@ weight: 10
|
||||
API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로
|
||||
`ResourceQuota`가 있는 경우 활성화된다.
|
||||
|
||||
해당 네임스페이스에 `ResourceQuota`가 있는 경우 특정 네임스페이스에
|
||||
해당 네임스페이스에 리소스쿼터가 있는 경우 특정 네임스페이스에
|
||||
리소스 쿼터가 적용된다.
|
||||
|
||||
## 컴퓨트 리소스 쿼터
|
||||
@@ -70,10 +70,14 @@ API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로
|
||||
|
||||
| 리소스 이름 | 설명 |
|
||||
| --------------------- | ----------------------------------------------------------- |
|
||||
| `limits.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 제한의 합은 이 값을 초과할 수 없음 |
|
||||
| `limits.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 제한의 합은 이 값을 초과할 수 없음 |
|
||||
| `requests.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 요청의 합은 이 값을 초과할 수 없음 |
|
||||
| `requests.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 요청의 합은 이 값을 초과할 수 없음 |
|
||||
| `limits.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 제한의 합은 이 값을 초과할 수 없음. |
|
||||
| `limits.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 제한의 합은 이 값을 초과할 수 없음. |
|
||||
| `requests.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 요청의 합은 이 값을 초과할 수 없음. |
|
||||
| `requests.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 요청의 합은 이 값을 초과할 수 없음. |
|
||||
| `hugepages-<size>` | 터미널 상태가 아닌 모든 파드에 걸쳐서, 지정된 사이즈의
|
||||
휴즈 페이지 요청은 이 값을 초과하지 못함. |
|
||||
| `cpu` | `requests.cpu` 와 같음. |
|
||||
| `memory` | `requests.memory` 와 같음. |
|
||||
|
||||
### 확장된 리소스에 대한 리소스 쿼터
|
||||
|
||||
@@ -103,7 +107,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
|
||||
| `requests.storage` | 모든 퍼시스턴트 볼륨 클레임에서 스토리지 요청의 합은 이 값을 초과할 수 없음 |
|
||||
| `persistentvolumeclaims` | 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 |
|
||||
| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | storage-class-name과 관련된 모든 퍼시스턴트 볼륨 클레임에서 스토리지 요청의 합은 이 값을 초과할 수 없음 |
|
||||
| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | storage-class-name과 관련된 모든 퍼시스턴트 볼륨 클레임에서 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 |
|
||||
| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | `<storage-class-name>` 과 관련된 모든 퍼시스턴트 볼륨 클레임에서 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 |
|
||||
|
||||
예를 들어, 운영자가 `bronze` 스토리지 클래스와 별도로 `gold` 스토리지 클래스를 사용하여 스토리지에 쿼터를 지정하려는 경우 운영자는 다음과 같이
|
||||
쿼터를 정의할 수 있다.
|
||||
@@ -115,14 +119,17 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
|
||||
|
||||
| 리소스 이름 | 설명 |
|
||||
| ------------------------------- |----------------------------------------------------------- |
|
||||
| `requests.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 요청의 합은 이 값을 초과할 수 없음 |
|
||||
| `limits.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 제한의 합은 이 값을 초과할 수 없음 |
|
||||
| `requests.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 요청의 합은 이 값을 초과할 수 없음. |
|
||||
| `limits.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 제한의 합은 이 값을 초과할 수 없음. |
|
||||
| `ephemeral-storage` | `requests.ephemeral-storage` 와 같음. |
|
||||
|
||||
## 오브젝트 수 쿼터
|
||||
|
||||
1.9 릴리스는 다음 구문을 사용하여 모든 표준 네임스페이스 리소스 유형에 쿼터를 지정하는 지원을 추가했다.
|
||||
다음 구문을 사용하여 모든 표준 네임스페이스 처리된(namespaced) 리소스 유형에 대한
|
||||
특정 리소스 전체 수에 대하여 쿼터를 지정할 수 있다.
|
||||
|
||||
* `count/<resource>.<group>`
|
||||
* 코어 그룹이 아닌(non-core) 리소스를 위한 `count/<resource>.<group>`
|
||||
* 코어 그룹의 리소스를 위한 `count/<resource>`
|
||||
|
||||
다음은 사용자가 오브젝트 수 쿼터 아래에 배치하려는 리소스 셋의 예이다.
|
||||
|
||||
@@ -136,32 +143,29 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
|
||||
* `count/statefulsets.apps`
|
||||
* `count/jobs.batch`
|
||||
* `count/cronjobs.batch`
|
||||
* `count/deployments.extensions`
|
||||
|
||||
1.15 릴리스는 동일한 구문을 사용하여 사용자 정의 리소스에 대한 지원을 추가했다.
|
||||
사용자 정의 리소스를 위해 동일한 구문을 사용할 수 있다.
|
||||
예를 들어 `example.com` API 그룹에서 `widgets` 사용자 정의 리소스에 대한 쿼터를 생성하려면 `count/widgets.example.com`을 사용한다.
|
||||
|
||||
`count/*` 리소스 쿼터를 사용할 때 서버 스토리지 영역에 있다면 오브젝트는 쿼터에 대해 과금된다.
|
||||
이러한 유형의 쿼터는 스토리지 리소스 고갈을 방지하는 데 유용하다. 예를 들어,
|
||||
크기가 큰 서버에서 시크릿 수에 쿼터를 지정할 수 있다. 클러스터에 시크릿이 너무 많으면 실제로 서버와
|
||||
컨트롤러가 시작되지 않을 수 있다! 네임스페이스에 너무 많은 작업을 생성하는
|
||||
잘못 구성된 크론 잡으로 인해 서비스 거부를 유발하는 것으로부터 보호하기 위해 작업의 쿼터를 지정하도록 선택할 수 있다.
|
||||
|
||||
1.9 릴리스 이전에는 제한된 리소스 셋에서 일반 오브젝트 수 쿼터를 적용할 수 있었다.
|
||||
또한, 특정 리소스에 대한 쿼터를 유형별로 추가로 제한할 수 있다.
|
||||
컨트롤러가 시작되지 않을 수 있다. 잘못 구성된 크론 잡으로부터의 보호를 위해
|
||||
잡의 쿼터를 설정할 수 있다. 네임스페이스 내에서 너무 많은 잡을 생성하는 크론 잡은 서비스 거부를 유발할 수 있다.
|
||||
|
||||
또한 제한된 리소스 셋에 대해서 일반 오브젝트 수(generic object count) 쿼터를 적용하는 것도 가능하다.
|
||||
다음 유형이 지원된다.
|
||||
|
||||
| 리소스 이름 | 설명 |
|
||||
| ------------------------------- | ------------------------------------------------- |
|
||||
| `configmaps` | 네임스페이스에 존재할 수 있는 총 구성 맵 수 |
|
||||
| `configmaps` | 네임스페이스에 존재할 수 있는 총 컨피그맵 수 |
|
||||
| `persistentvolumeclaims` | 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 |
|
||||
| `pods` | 네임스페이스에 존재할 수 있는 터미널이 아닌 상태의 파드의 총 수. `.status.phase in (Failed, Succeeded)`가 true인 경우 파드는 터미널 상태임 |
|
||||
| `replicationcontrollers` | 네임스페이스에 존재할 수 있는 총 레플리케이션 컨트롤러 수 |
|
||||
| `resourcequotas` | 네임스페이스에 존재할 수 있는 총 [리소스 쿼터](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) 수 |
|
||||
| `replicationcontrollers` | 네임스페이스에 존재할 수 있는 총 레플리케이션컨트롤러 수 |
|
||||
| `resourcequotas` | 네임스페이스에 존재할 수 있는 총 리소스쿼터 수 |
|
||||
| `services` | 네임스페이스에 존재할 수 있는 총 서비스 수 |
|
||||
| `services.loadbalancers` | 네임스페이스에 존재할 수 있는 로드 밸런서 유형의 총 서비스 수 |
|
||||
| `services.nodeports` | 네임스페이스에 존재할 수 있는 노드 포트 유형의 총 서비스 수 |
|
||||
| `services.loadbalancers` | 네임스페이스에 존재할 수 있는 `LoadBalancer` 유형의 총 서비스 수 |
|
||||
| `services.nodeports` | 네임스페이스에 존재할 수 있는 `NodePort` 유형의 총 서비스 수 |
|
||||
| `secrets` | 네임스페이스에 존재할 수 있는 총 시크릿 수 |
|
||||
|
||||
예를 들어, `pods` 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 `pods` 수를
|
||||
@@ -171,7 +175,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
|
||||
|
||||
## 쿼터 범위
|
||||
|
||||
각 쿼터에는 연결된 범위 셋이 있을 수 있다. 쿼터는 열거된 범위의 교차 부분과 일치하는 경우에만
|
||||
각 쿼터에는 연결된 `scopes` 셋이 있을 수 있다. 쿼터는 열거된 범위의 교차 부분과 일치하는 경우에만
|
||||
리소스 사용량을 측정한다.
|
||||
|
||||
범위가 쿼터에 추가되면 해당 범위와 관련된 리소스를 지원하는 리소스 수가 제한된다.
|
||||
@@ -183,22 +187,60 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
|
||||
| `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 |
|
||||
| `BestEffort` | 최상의 서비스 품질을 제공하는 파드 |
|
||||
| `NotBestEffort` | 서비스 품질이 나쁜 파드 |
|
||||
| `PriorityClass` | 지정된 [프라이올리티 클래스](/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
|
||||
|
||||
`BestEffort` 범위는 다음의 리소스(파드)를 추적하도록 쿼터를 제한한다.
|
||||
`BestEffort` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다.
|
||||
|
||||
`Terminating`, `NotTerminating` 및 `NotBestEffort` 범위는 쿼터를 제한하여 다음의 리소스를 추적한다.
|
||||
|
||||
* `cpu`
|
||||
* `limits.cpu`
|
||||
* `limits.memory`
|
||||
* `memory`
|
||||
* `pods`
|
||||
|
||||
`Terminating`, `NotTerminating`, `NotBestEffort` 및 `PriorityClass`
|
||||
범위는 쿼터를 제한하여 다음의 리소스를 추적한다.
|
||||
|
||||
* `pods`
|
||||
* `cpu`
|
||||
* `memory`
|
||||
* `requests.cpu`
|
||||
* `requests.memory`
|
||||
* `limits.cpu`
|
||||
* `limits.memory`
|
||||
|
||||
`Terminating` 과 `NotTerminating` 범위를 동일한 쿼터 내에 모두
|
||||
명시하지는 못하며, 마찬가지로 `BestEffort` 와
|
||||
`NotBestEffort` 범위도 동일한 쿼터 내에서 모두 명시하지는 못한다.
|
||||
|
||||
`scopeSelector` 는 `operator` 필드에 다음의 값을 지원한다.
|
||||
|
||||
* `In`
|
||||
* `NotIn`
|
||||
* `Exists`
|
||||
* `DoesNotExist`
|
||||
|
||||
`scopeSelector` 를 정의할 때, `scopeName` 으로 다음의 값 중 하나를 사용하는
|
||||
경우, `operator` 는 `Exists` 이어야 한다.
|
||||
|
||||
* `Terminating`
|
||||
* `NotTerminating`
|
||||
* `BestEffort`
|
||||
* `NotBestEffort`
|
||||
|
||||
만약 `operator` 가 `In` 또는 `NotIn` 인 경우, `values` 필드는 적어도 하나의 값은
|
||||
가져야 한다. 예를 들면 다음과 같다.
|
||||
|
||||
```yaml
|
||||
scopeSelector:
|
||||
matchExpressions:
|
||||
- scopeName: PriorityClass
|
||||
operator: In
|
||||
values:
|
||||
- middle
|
||||
```
|
||||
|
||||
만약 `operator` 가 `Exists` 또는 `DoesNotExist` 이라면, `values` 필드는 명시되면
|
||||
*안된다*.
|
||||
|
||||
### PriorityClass별 리소스 쿼터
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
|
||||
|
||||
특정 [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/#파드-우선순위)로 파드를 생성할 수 있다.
|
||||
쿼터 스펙의 `scopeSelector` 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을
|
||||
@@ -281,7 +323,7 @@ items:
|
||||
kubectl create -f ./quota.yml
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
resourcequota/pods-high created
|
||||
resourcequota/pods-medium created
|
||||
resourcequota/pods-low created
|
||||
@@ -293,7 +335,7 @@ resourcequota/pods-low created
|
||||
kubectl describe quota
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
Name: pods-high
|
||||
Namespace: default
|
||||
Resource Used Hard
|
||||
@@ -358,7 +400,7 @@ kubectl create -f ./high-priority-pod.yml
|
||||
kubectl describe quota
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
Name: pods-high
|
||||
Namespace: default
|
||||
Resource Used Hard
|
||||
@@ -386,13 +428,6 @@ memory 0 20Gi
|
||||
pods 0 10
|
||||
```
|
||||
|
||||
`scopeSelector`는 `operator` 필드에서 다음 값을 지원한다.
|
||||
|
||||
* `In`
|
||||
* `NotIn`
|
||||
* `Exist`
|
||||
* `DoesNotExist`
|
||||
|
||||
## 요청과 제한의 비교 {#requests-vs-limits}
|
||||
|
||||
컴퓨트 리소스를 할당할 때 각 컨테이너는 CPU 또는 메모리에 대한 요청과 제한값을 지정할 수 있다.
|
||||
@@ -456,7 +491,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace
|
||||
kubectl get quota --namespace=myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
NAME AGE
|
||||
compute-resources 30s
|
||||
object-counts 32s
|
||||
@@ -466,7 +501,7 @@ object-counts 32s
|
||||
kubectl describe quota compute-resources --namespace=myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
Name: compute-resources
|
||||
Namespace: myspace
|
||||
Resource Used Hard
|
||||
@@ -482,7 +517,7 @@ requests.nvidia.com/gpu 0 4
|
||||
kubectl describe quota object-counts --namespace=myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
Name: object-counts
|
||||
Namespace: myspace
|
||||
Resource Used Hard
|
||||
@@ -504,7 +539,7 @@ kubectl create namespace myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace
|
||||
kubectl create quota test --hard=count/deployments.apps=2,count/replicasets.apps=4,count/pods=3,count/secrets=4 --namespace=myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
@@ -515,29 +550,29 @@ kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2
|
||||
kubectl describe quota --namespace=myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
Name: test
|
||||
Namespace: myspace
|
||||
Resource Used Hard
|
||||
-------- ---- ----
|
||||
count/deployments.extensions 1 2
|
||||
count/deployments.apps 1 2
|
||||
count/pods 2 3
|
||||
count/replicasets.extensions 1 4
|
||||
count/replicasets.apps 1 4
|
||||
count/secrets 1 4
|
||||
```
|
||||
|
||||
## 쿼터 및 클러스터 용량
|
||||
|
||||
`ResourceQuotas`는 클러스터 용량과 무관하다. 그것들은 절대 단위로 표현된다.
|
||||
리소스쿼터는 클러스터 용량과 무관하다. 그것들은 절대 단위로 표현된다.
|
||||
따라서 클러스터에 노드를 추가해도 각 네임스페이스에 더 많은 리소스를
|
||||
사용할 수 있는 기능이 자동으로 부여되지는 *않는다*.
|
||||
|
||||
가끔 다음과 같은 보다 복잡한 정책이 필요할 수 있다.
|
||||
|
||||
- 여러 팀으로 전체 클러스터 리소스를 비례적으로 나눈다.
|
||||
- 각 테넌트가 필요에 따라 리소스 사용량을 늘릴 수 있지만, 실수로 리소스가 고갈되는 것을
|
||||
막기 위한 충분한 제한이 있다.
|
||||
- 하나의 네임스페이스에서 요구를 감지하고 노드를 추가하며 쿼터를 늘린다.
|
||||
- 여러 팀으로 전체 클러스터 리소스를 비례적으로 나눈다.
|
||||
- 각 테넌트가 필요에 따라 리소스 사용량을 늘릴 수 있지만, 실수로 리소스가 고갈되는 것을
|
||||
막기 위한 충분한 제한이 있다.
|
||||
- 하나의 네임스페이스에서 요구를 감지하고 노드를 추가하며 쿼터를 늘린다.
|
||||
|
||||
이러한 정책은 쿼터 사용을 감시하고 다른 신호에 따라 각 네임스페이스의 쿼터 하드 제한을
|
||||
조정하는 "컨트롤러"를 작성하여 `ResourceQuotas`를 구성 요소로
|
||||
@@ -548,14 +583,16 @@ count/secrets 1 4
|
||||
|
||||
## 기본적으로 우선 순위 클래스 소비 제한
|
||||
|
||||
파드가 특정 우선 순위, 예를 들어 일치하는 쿼터 오브젝트가 존재하는 경우에만 "cluster-services"가 네임스페이스에 허용되어야 힌다.
|
||||
파드가 특정 우선 순위, 예를 들어 일치하는 쿼터 오브젝트가 존재하는
|
||||
경우에만 "cluster-services"가 네임스페이스에 허용되어야 한다.
|
||||
|
||||
이 메커니즘을 통해 운영자는 특정 우선 순위가 높은 클래스의 사용을 제한된 수의 네임스페이스로 제한할 수 있으며 모든 네임스페이스가 기본적으로 이러한 우선 순위 클래스를 사용할 수 있는 것은 아니다.
|
||||
이 메커니즘을 통해 운영자는 특정 우선 순위가 높은 클래스의 사용을
|
||||
제한된 수의 네임스페이스로 제한할 수 있으며 모든 네임스페이스가
|
||||
기본적으로 이러한 우선 순위 클래스를 사용할 수 있는 것은 아니다.
|
||||
|
||||
이를 적용하려면 kube-apiserver 플래그 `--admission-control-config-file`을 사용하여 다음 구성 파일의 경로를 전달해야 한다.
|
||||
이를 적용하려면 kube-apiserver 플래그 `--admission-control-config-file` 을
|
||||
사용하여 다음 구성 파일의 경로를 전달해야 한다.
|
||||
|
||||
{{< tabs name="example1" >}}
|
||||
{{% tab name="apiserver.config.k8s.io/v1" %}}
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: AdmissionConfiguration
|
||||
@@ -571,30 +608,10 @@ plugins:
|
||||
operator: In
|
||||
values: ["cluster-services"]
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="apiserver.k8s.io/v1alpha1" %}}
|
||||
```yaml
|
||||
# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1
|
||||
apiVersion: apiserver.k8s.io/v1alpha1
|
||||
kind: AdmissionConfiguration
|
||||
plugins:
|
||||
- name: "ResourceQuota"
|
||||
configuration:
|
||||
# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1, ResourceQuotaConfiguration
|
||||
apiVersion: resourcequota.admission.k8s.io/v1beta1
|
||||
kind: Configuration
|
||||
limitedResources:
|
||||
- resource: pods
|
||||
matchScopes:
|
||||
- scopeName: PriorityClass
|
||||
operator: In
|
||||
values: ["cluster-services"]
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
이제 "cluster-services" 파드는 `scopeSelector`와 일치하는 쿼터 오브젝트가 있는 네임스페이스에서만 허용된다.
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
```yaml
|
||||
scopeSelector:
|
||||
matchExpressions:
|
||||
@@ -603,12 +620,9 @@ plugins:
|
||||
values: ["cluster-services"]
|
||||
```
|
||||
|
||||
자세한 내용은 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)와 [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)를 참고하길 바란다.
|
||||
|
||||
## 예제
|
||||
|
||||
[리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고하길 바란다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다.
|
||||
- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고한다.
|
||||
- [리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고한다.
|
||||
- [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)를 읽는다.
|
||||
- [제한된 자원](https://github.com/kubernetes/kubernetes/pull/36765)을 참고한다.
|
||||
|
||||
@@ -78,7 +78,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
|
||||
방법이 있다.
|
||||
|
||||
1. [스케줄링 정책](/docs/reference/scheduling/config/#profiles)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다.
|
||||
1. [스케줄링 프로파일](/docs/reference/scheduling/profiles)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.
|
||||
1. [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
@@ -88,8 +88,8 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
|
||||
* kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
|
||||
* [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
|
||||
* [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
|
||||
* [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기
|
||||
* 볼륨을 사용하느 파드의 스케줄링에 대해 배우기
|
||||
* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기
|
||||
* 볼륨을 사용하는 파드의 스케줄링에 대해 배우기
|
||||
* [볼륨 토폴리지 지원](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)
|
||||
* [스토리지 용량 추적](/docs/concepts/storage/storage-capacity/)
|
||||
* [노드별 볼륨 한도](/ko/docs/concepts/storage/storage-limits/)
|
||||
|
||||
@@ -0,0 +1,161 @@
|
||||
---
|
||||
title: 쿠버네티스 API 접근 제어하기
|
||||
content_type: concept
|
||||
weight: 5
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
이 페이지는 쿠버네티스 API에 대한 접근 제어의 개요를 제공한다.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
사용자는 `kubectl`, 클라이언트 라이브러리
|
||||
또는 REST 요청을 통해
|
||||
[API에 접근한다](/ko/docs/tasks/access-application-cluster/access-cluster/).
|
||||
사용자와 쿠버네티스 서비스 어카운트 모두 API에 접근할 수 있다.
|
||||
요청이 API에 도달하면,
|
||||
다음 다이어그램에 설명된 몇 가지 단계를 거친다.
|
||||
|
||||
|
||||
|
||||
## 전송 보안
|
||||
|
||||
일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다.
|
||||
API 서버는 인증서를 제시한다.
|
||||
이 인증서는 종종 자체 서명되기 때문에 일반적으로 사용자 머신의 `$USER/.kube/config`는
|
||||
API 서버의 인증서에 대한 루트 인증서를 포함하며,
|
||||
시스템 기본 루트 인증서 대신 사용된다.
|
||||
`kube-up.sh`을 사용하여 클러스터를 직접 생성할 때
|
||||
이 인증서는 일반적으로 `$USER/.kube/config`에 자동으로 기록된다.
|
||||
클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다.
|
||||
|
||||
## 인증
|
||||
|
||||
TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다.
|
||||
이는 다이어그램에 **1**단계로 표시되어 있다.
|
||||
클러스터 생성 스크립트 또는 클러스터 관리자는
|
||||
API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
|
||||
인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
|
||||
|
||||
인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
|
||||
일반적으로 헤더 그리고/또는 클라이언트 인증서만 검사한다.
|
||||
|
||||
인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰,
|
||||
JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
|
||||
|
||||
여러 개의 인증 모듈을 지정할 수 있으며,
|
||||
이 경우 하나의 인증 모듈이 성공할 때까지 각 모듈을 순차적으로 시도한다.
|
||||
|
||||
GCE에서는 클라이언트 인증서, 암호, 일반 토큰 및 JWT 토큰이 모두 사용 가능하다.
|
||||
|
||||
요청을 인증할 수 없는 경우 HTTP 상태 코드 401과 함께 거부된다.
|
||||
이 외에는 사용자가 특정 `username`으로 인증되며,
|
||||
이 username은 다음 단계에서 사용자의 결정에 사용할 수 있다.
|
||||
일부 인증기는 사용자 그룹 관리 기능을 제공하는 반면,
|
||||
이외의 인증기는 그렇지 않다.
|
||||
|
||||
쿠버네티스는 접근 제어 결정과 요청 기록 시 `usernames`를 사용하지만,
|
||||
`user` 오브젝트를 가지고 있지 않고 usernames 나 기타 사용자 정보를
|
||||
오브젝트 저장소에 저장하지도 않는다.
|
||||
|
||||
## 인가
|
||||
|
||||
특정 사용자로부터 온 요청이 인증된 후에는 인가되어야 한다. 이는 다이어그램에 **2**단계로 표시되어 있다.
|
||||
|
||||
요청은 요청자의 username, 요청된 작업 및 해당 작업이 영향을 주는 오브젝트를 포함해야 한다. 기존 정책이 요청된 작업을 완료할 수 있는 권한이 해당 사용자에게 있다고 선언하는 경우 요청이 인가된다.
|
||||
|
||||
예를 들어 Bob이 아래와 같은 정책을 가지고 있다면 `projectCaribou` 네임스페이스에서만 파드를 읽을 수 있다.
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
|
||||
"kind": "Policy",
|
||||
"spec": {
|
||||
"user": "bob",
|
||||
"namespace": "projectCaribou",
|
||||
"resource": "pods",
|
||||
"readonly": true
|
||||
}
|
||||
}
|
||||
```
|
||||
Bob이 다음과 같은 요청을 하면 'projectCaribou' 네임스페이스의 오브젝트를 읽을 수 있기 때문에 요청이 인가된다.
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "authorization.k8s.io/v1beta1",
|
||||
"kind": "SubjectAccessReview",
|
||||
"spec": {
|
||||
"resourceAttributes": {
|
||||
"namespace": "projectCaribou",
|
||||
"verb": "get",
|
||||
"group": "unicorn.example.org",
|
||||
"resource": "pods"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`create` 또는 `update`) 요청을 하면 그의 인가는 거부된다. 만약 Bob이 `projectFish`처럼 다른 네임스페이스의 오브젝트 읽기(`get`) 요청을 하면 그의 인가는 거부된다.
|
||||
|
||||
쿠버네티스 인가는 공통 REST 속성을 사용하여 기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 상호 작용할 것을 요구한다. 이러한 제어 시스템은 쿠버네티스 API 이외의 다른 API와 상호작용할 수 있으므로 REST 형식을 사용하는 것이 중요하다.
|
||||
|
||||
쿠버네티스는 ABAC 모드, RBAC 모드, 웹훅 모드와 같은 여러 개의 인가 모듈을 지원한다. 관리자가 클러스터를 생성할 때 API 서버에서 사용해야 하는 인가 모듈을 구성했다. 인가 모듈이 2개 이상 구성되면 쿠버네티스가 각 모듈을 확인하고, 어느 모듈이 요청을 승인하면 요청을 진행할 수 있다. 모든 모듈이 요청을 거부하면 요청이 거부된다(HTTP 상태 코드 403).
|
||||
|
||||
인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면 [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)를 참조한다.
|
||||
|
||||
|
||||
## 어드미션 제어
|
||||
|
||||
어드미션 제어 모듈은 요청을 수정하거나 거부할 수 있는 소프트웨어 모듈이다.
|
||||
인가 모듈에서 사용할 수 있는 속성 외에도
|
||||
어드미션 제어 모듈은 생성되거나 수정된 오브젝트 내용에 접근할 수 있다.
|
||||
|
||||
어드미션 컨트롤러는 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동한다.
|
||||
어드미션 컨트롤러는 단순히 객체를 읽는 요청에는 작동하지 않는다.
|
||||
여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다.
|
||||
|
||||
이는 다이어그램에 **3**단계로 표시되어 있다.
|
||||
|
||||
인증 및 인가 모듈과 달리,
|
||||
어드미션 제어 모듈이 거부되면 요청은 즉시 거부된다.
|
||||
|
||||
어드미션 제어 모듈은 오브젝트를 거부하는 것 외에도
|
||||
필드의 복잡한 기본값을 설정할 수 있다.
|
||||
|
||||
사용 가능한 어드미션 제어 모듈은 [여기](/docs/reference/access-authn-authz/admission-controllers/)에 서술되어 있다.
|
||||
|
||||
요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후
|
||||
오브젝트 저장소에 기록(**4**단계)된다.
|
||||
|
||||
|
||||
## API 서버 포트와 IP
|
||||
|
||||
이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다.
|
||||
API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다.
|
||||
|
||||
기본적으로 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.
|
||||
|
||||
1. `로컬호스트 포트`:
|
||||
|
||||
- 테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소
|
||||
(스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다.
|
||||
- TLS가 없다.
|
||||
- 기본 포트는 8080이며, `--insecure-port` 플래그를 사용하여 변경한다.
|
||||
- 기본 IP는 로컬호스트(localhost)이며, `--insecure-bind-address` 플래그를 사용하여 변경한다.
|
||||
- 요청이 인증 및 인가 모듈을 **우회한다**.
|
||||
- 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
|
||||
- 호스트 접근 요구로부터 보호를 받는다.
|
||||
|
||||
2. `보안 포트`:
|
||||
|
||||
- 가능한 항상 사용하는 것이 좋다.
|
||||
- TLS를 사용한다. `--tls-cert-file` 플래그로 인증서를 지정하고 `--tls-private-key-file` 플래그로 키를 지정한다.
|
||||
- 기본 포트는 6443이며, `--secure-port` 플래그를 사용하여 변경한다.
|
||||
- 기본 IP는 로컬호스트가 아닌 첫 번째 네트워크 인터페이스이며, `--bind-address` 플래그를 사용하여 변경한다.
|
||||
- 요청이 인증 및 인가 모듈에 의해 처리된다.
|
||||
- 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
|
||||
- 인증 및 인가 모듈을 실행한다.
|
||||
|
||||
GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 `kube-up.sh`로 클러스터를 생성하면
|
||||
API 서버는 포트 443에서 서비스한다.
|
||||
GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다.
|
||||
이외에 클러스터 설정 방법은 다양하다.
|
||||
@@ -102,7 +102,7 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋
|
||||
워크로드 보안에서 고려할 영역 | 추천 |
|
||||
------------------------------ | ------------ |
|
||||
RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
|
||||
인증 | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/
|
||||
인증 | https://kubernetes.io/ko/docs/concepts/security/controlling-access/
|
||||
애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
|
||||
파드 보안 정책 | https://kubernetes.io/docs/concepts/policy/pod-security-policy/
|
||||
서비스 품질(및 클러스터 리소스 관리) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
|
||||
@@ -146,8 +146,8 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리
|
||||
|
||||
* [파드 보안 표준](/docs/concepts/security/pod-security-standards/)
|
||||
* [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/)
|
||||
* [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access)
|
||||
* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)
|
||||
* [API 접근 통제](/ko/docs/reference/access-authn-authz/controlling-access/)
|
||||
* 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/)
|
||||
* [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/)
|
||||
* [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
|
||||
|
||||
@@ -94,7 +94,7 @@ IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급
|
||||
|
||||
## 이그레스 트래픽
|
||||
|
||||
근본적으로 {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 전송을 구현할 수 있는 경우 공개적으로 라우팅 하거나 비공개 라우팅만 가능한 IPv6 주소 블록의 사용은 허용된다. 만약 비공개 라우팅만 가능한 IPv6를 사용하는 파드가 있고, 해당 파드가 오프 클러스터 목적지(예: 공용 인터넷)에 도달하기를 원하는 경우에는 이그레스 트래픽과 모든 응답을 위한 마스커레이딩 IP를 설정해야 한다. [ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 는 이중 스택을 인식하기에, 이중 스택 클러스터에서 마스커레이딩 IP에 ip-masq-agent 를 사용할 수 있다.
|
||||
근본적으로 {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 전송을 구현할 수 있는 경우 공개적으로 라우팅 하거나 비공개 라우팅만 가능한 IPv6 주소 블록의 사용은 허용된다. 만약 비공개 라우팅만 가능한 IPv6를 사용하는 파드가 있고, 해당 파드가 오프 클러스터 목적지(예: 공용 인터넷)에 도달하기를 원하는 경우에는 이그레스 트래픽과 모든 응답을 위한 마스커레이딩 IP를 설정해야 한다. [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)는 이중 스택을 인식하기에, 이중 스택 클러스터에서 마스커레이딩 IP에 ip-masq-agent를 사용할 수 있다.
|
||||
|
||||
## 알려진 이슈들
|
||||
|
||||
|
||||
@@ -411,6 +411,13 @@ type: kubernetes.io/tls
|
||||
TLS 시크릿이 `https-example.foo.com` 의 정규화 된 도메인 이름(FQDN)이라고
|
||||
하는 일반 이름(CN)을 포함하는 인증서에서 온 것인지 확인해야 한다.
|
||||
|
||||
{{< note >}}
|
||||
가능한 모든 하위 도메인에 대해 인증서가 발급되어야 하기 때문에
|
||||
TLS는 기본 규칙에서 작동하지 않는다. 따라서
|
||||
`tls` 섹션의 `hosts`는 `rules`섹션의 `host`와 명시적으로 일치해야
|
||||
한다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
|
||||
|
||||
{{< note >}}
|
||||
|
||||
@@ -177,27 +177,29 @@ spec:
|
||||
퍼시스턴트볼륨이 존재하고 `claimRef` 필드를 통해 퍼시스턴트볼륨클레임을 예약하지 않은 경우, 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이 바인딩된다.
|
||||
|
||||
바인딩은 노드 선호도(affinity)를 포함하여 일부 볼륨 일치(matching) 기준과 관계없이 발생한다.
|
||||
컨트롤 플레인은 여전히 [스토리지 클래스](https://kubernetes.io/ko/docs/concepts/storage/storage-classes/), 접근 모드 및 요청된 스토리지 크기가 유효한지 확인한다.
|
||||
컨트롤 플레인은 여전히 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes/), 접근 모드 및 요청된 스토리지 크기가 유효한지 확인한다.
|
||||
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: foo-pvc
|
||||
namespace: foo
|
||||
spec:
|
||||
storageClassName: "" # 빈 문자열은 명시적으로 설정해야 하며 그렇지 않으면 기본 스토리지클래스가 설정됨
|
||||
volumeName: foo-pv
|
||||
...
|
||||
```
|
||||
|
||||
이 메서드는 퍼시스턴트볼륨에 대한 바인딩 권한을 보장하지 않는다. 다른 퍼시스턴트볼륨클레임에서 지정한 PV를 사용할 수 있는 경우, 먼저 해당 스토리지 볼륨을 예약해야 한다. PV의 `claimRef` 필드에 관련 퍼시스턴트볼륨클레임을 지정하여 다른 PVC가 바인딩할 수 없도록 한다.
|
||||
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
metadata:
|
||||
name: foo-pv
|
||||
spec:
|
||||
storageClassName: ""
|
||||
claimRef:
|
||||
name: foo-pvc
|
||||
namespace: foo
|
||||
|
||||
@@ -89,7 +89,7 @@ volumeBindingMode: Immediate
|
||||
등에 대한 완전한 재량권을 가진다. [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
|
||||
리포지터리에는 대량의 사양을 구현하는 외부 프로비저너를 작성하기
|
||||
위한 라이브러리가 있다. 일부 외부 프로비저너의 목록은
|
||||
[kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage) 리포지터리에 있다.
|
||||
[kubernetes-sigs/external-storage](https://github.com/kubernetes-sigs/external-dns) 리포지터리에 있다.
|
||||
|
||||
예를 들어, NFS는 내부 프로비저너를 제공하지 않지만, 외부
|
||||
프로비저너를 사용할 수 있다. 타사 스토리지 업체가 자체 외부
|
||||
|
||||
@@ -24,6 +24,8 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및
|
||||
|
||||
`VolumeSnapshotClass` 을 사용하면 `VolumeSnapshot` 에 속한 다른 속성을 지정할 수 있다. 이러한 속성은 스토리지 시스템에의 동일한 볼륨에서 가져온 스냅샷마다 다를 수 있으므로 `PersistentVolumeClaim` 의 `StorageClass` 를 사용하여 표현할 수는 없다.
|
||||
|
||||
볼륨 스냅샷은 쿠버네티스 사용자에게 완전히 새로운 볼륨을 생성하지 않고도 특정 시점에 볼륨의 콘텐츠를 복사하는 표준화된 방법을 제공한다. 예를 들어, 데이터베이스 관리자는 이 기능을 사용하여 수정 사항을 편집 또는 삭제하기 전에 데이터베이스를 백업할 수 있다.
|
||||
|
||||
사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다.
|
||||
|
||||
* API 객체인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -32,7 +32,7 @@ no_list: true
|
||||
파드를 실행하기 위한 [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/)
|
||||
* 완료될 때까지 실행되는 작업에 대한
|
||||
[잡(Job)](/ko/docs/concepts/workloads/controllers/job/) 및
|
||||
[크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cronjob/)
|
||||
[크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)
|
||||
|
||||
관련성을 찾을 수 있는 두 가지 지원 개념도 있다.
|
||||
* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
|
||||
|
||||
@@ -229,7 +229,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
|
||||
|
||||
### 파드 템플릿
|
||||
|
||||
`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다.
|
||||
`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
|
||||
우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다.
|
||||
이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.
|
||||
|
||||
|
||||
@@ -77,13 +77,13 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
|
||||
|
||||
`phase`에 가능한 값은 다음과 같다.
|
||||
|
||||
값 | 의미
|
||||
:-----|:-----------
|
||||
`Pending` | 파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았다. 여기에는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함된다.
|
||||
`Running` | 파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되었다. 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있다.
|
||||
값 | 의미
|
||||
:-----------|:-----------
|
||||
`Pending` | 파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았다. 여기에는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함된다.
|
||||
`Running` | 파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되었다. 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있다.
|
||||
`Succeeded` | 파드에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작되지 않을 것이다.
|
||||
`Failed` | 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다.
|
||||
`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다.
|
||||
`Failed` | 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다.
|
||||
`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다.
|
||||
|
||||
노드가 죽거나 클러스터의 나머지와의 연결이 끊어지면, 쿠버네티스는
|
||||
손실된 노드의 모든 파드의 `phase` 를 Failed로 설정하는 정책을 적용한다.
|
||||
@@ -229,7 +229,8 @@ kubelet은 파드의 [조건](#파드의-조건)을 `ContainerReady` 로 설정
|
||||
## 컨테이너 프로브(probe)
|
||||
|
||||
[프로브](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)는
|
||||
컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다.
|
||||
컨테이너에서 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 의해
|
||||
주기적으로 수행되는 진단(diagnostic)이다.
|
||||
진단을 수행하기 위해서,
|
||||
kubelet은 컨테이너에 의해서 구현된
|
||||
[핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다.
|
||||
|
||||
@@ -4,11 +4,21 @@ content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
|
||||
<!-- leave this shortcode in place until the note about EvenPodsSpread is
|
||||
obsolete -->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.
|
||||
|
||||
|
||||
{{< note >}}
|
||||
v1.19 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면
|
||||
[API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와
|
||||
[스케줄러](/docs/reference/generated/kube-scheduler/)에서
|
||||
`EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
활성화해야 한다
|
||||
{{< /note >}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
||||
Reference in New Issue
Block a user