Merge pull request #24592 from kubernetes/dev-1.19-ko.3
Third Korean l10n work for release-1.19
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
6d050e326b
|
|
@ -16,7 +16,7 @@ aliases:
|
|||
|
||||
## 노드에서 컨트롤 플레인으로의 통신
|
||||
쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
|
||||
특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.
|
||||
특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/ko/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.
|
||||
|
||||
노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -47,11 +47,11 @@ no_list: true
|
|||
|
||||
* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
|
||||
|
||||
* [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다.
|
||||
* [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다.
|
||||
|
||||
* [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다.
|
||||
|
||||
* [인가](/docs/reference/access-authn-authz/authorization/)는 인증과는 별개로, HTTP 호출 처리 방법을 제어한다.
|
||||
* [인가](/ko/docs/reference/access-authn-authz/authorization/)는 인증과는 별개로, HTTP 호출 처리 방법을 제어한다.
|
||||
|
||||
* [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -214,6 +214,7 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
|
|||
전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파
|
||||
지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).
|
||||
|
||||
환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다.
|
||||
## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
|
|
|||
|
|
@ -134,7 +134,6 @@ spec:
|
|||
containers:
|
||||
- name: app
|
||||
image: images.my-company.example/app:v4
|
||||
env:
|
||||
resources:
|
||||
requests:
|
||||
memory: "64Mi"
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ weight: 70
|
|||
|
||||
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
|
||||
|
||||
[파드](/ko/docs/concepts/workloads/pods/pod/)는 _우선순위_ 를 가질 수 있다. 우선순위는
|
||||
[파드](/ko/docs/concepts/workloads/pods/)는 _우선순위_ 를 가질 수 있다. 우선순위는
|
||||
다른 파드에 대한 상대적인 파드의 중요성을 나타낸다. 파드를 스케줄링할 수 없는 경우,
|
||||
스케줄러는 우선순위가 낮은 파드를 선점(축출)하여 보류 중인 파드를
|
||||
스케줄링할 수 있게 한다.
|
||||
|
|
|
|||
|
|
@ -35,6 +35,12 @@ weight: 30
|
|||
- [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
|
||||
- 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
|
||||
|
||||
시크릿 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.
|
||||
|
||||
`data` 와 `stringData` 의 키는 영숫자 및 `-`, `_` 또는 `.` 으로
|
||||
구성되어야 한다.
|
||||
|
||||
### 빌트인 시크릿
|
||||
|
||||
#### 서비스 어카운트는 API 자격 증명으로 시크릿을 자동으로 생성하고 연결함
|
||||
|
|
@ -50,401 +56,15 @@ weight: 30
|
|||
서비스 어카운트 작동 방식에 대한 자세한 내용은
|
||||
[서비스어카운트(ServiceAccount)](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 참고한다.
|
||||
|
||||
### 자신만의 시크릿 생성하기
|
||||
### 시크릿 생성하기
|
||||
|
||||
#### `kubectl` 사용하여 시크릿 생성하기
|
||||
시크릿을 생성하기 위한 몇 가지 옵션이 있다.
|
||||
|
||||
시크릿에는 파드가 데이터베이스에 접근하는 데 필요한 사용자 자격 증명이 포함될 수 있다.
|
||||
예를 들어, 데이터베이스 연결 문자열은
|
||||
사용자명(username)과 비밀번호(password)로 구성된다. 사용자명은 `./username.txt` 파일에
|
||||
저장하고 비밀번호는 로컬 시스템의 `./password.txt` 파일에 저장할 수 있다.
|
||||
- [`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/)
|
||||
|
||||
```shell
|
||||
# 예제를 위해서 필요한 파일들을 생성한다.
|
||||
echo -n 'admin' > ./username.txt
|
||||
echo -n '1f2d1e2e67df' > ./password.txt
|
||||
```
|
||||
|
||||
`kubectl create secret` 명령은 이러한 파일을 시크릿으로 패키징하고
|
||||
API 서버에 오브젝트를 생성한다.
|
||||
시크릿 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
secret "db-user-pass" created
|
||||
```
|
||||
|
||||
기본 키 이름은 파일명(filename)이다. 선택적으로 `--from-file=[key=]source]` 를 사용하여 키 이름을 설정할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`$`, `\`, `*`, `=`, 그리고 `!` 등의 특수 문자는 [셸](https://ko.wikipedia.org/wiki/셸)에 의해 해석되고 이스케이핑이 필요하다.
|
||||
대부분의 셸에서, 비밀번호를 이스케이프하는 가장 쉬운 방법은 작은 따옴표(`'`)로 묶는 것이다.
|
||||
예를 들어, 실제 비밀번호가 `S!B\*d$zDsb=` 이면, 다음과 같은 명령을 실행해야 한다.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb='
|
||||
```
|
||||
|
||||
파일(`--from-file`)에서는 비밀번호의 특수 문자를 이스케이프할 필요가 없다.
|
||||
{{< /note >}}
|
||||
|
||||
다음의 명령으로 시크릿이 생성되었는지 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get secrets
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
db-user-pass Opaque 2 51s
|
||||
```
|
||||
|
||||
시크릿에 대한 설명을 볼 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl describe secrets/db-user-pass
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
Name: db-user-pass
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
password.txt: 12 bytes
|
||||
username.txt: 5 bytes
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`kubectl get` 명령과 `kubectl describe` 명령은 기본적으로 시크릿의 내용을 표시하지
|
||||
않는다. 이는 시크릿이 우연히 다른 사람에게 노출되거나,
|
||||
터미널 로그에 저장되지 않도록 보호하기 위함이다.
|
||||
{{< /note >}}
|
||||
|
||||
시크릿 내용을 보는 방법을 익히기 위해서는 [시크릿 디코딩하기](#시크릿-디코딩하기)를 참고한다.
|
||||
|
||||
#### 수동으로 시크릿 생성하기
|
||||
|
||||
먼저 JSON 또는 YAML 형식으로 파일에 시크릿을 생성한
|
||||
다음 해당 오브젝트를 생성할 수도 있다.
|
||||
시크릿 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
|
||||
[시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)은
|
||||
두 개의 맵(`data` 와 `stringData`)을
|
||||
포함한다. `data` 필드는 base64를 사용하여, 인코딩된 임의 데이터를 저장하는 데
|
||||
사용된다. `stringData` 필드는 편의를 위해 제공되며, 시크릿 데이터를 인코딩되지 않은
|
||||
문자열로 제공할 수 있다.
|
||||
|
||||
예를 들어, `data` 필드를 사용하여 시크릿에 두 개의 문자열을 저장하려면, 다음과 같이
|
||||
문자열을 base64로 변환한다.
|
||||
|
||||
```shell
|
||||
echo -n 'admin' | base64
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
YWRtaW4=
|
||||
```
|
||||
|
||||
```shell
|
||||
echo -n '1f2d1e2e67df' | base64
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
MWYyZDFlMmU2N2Rm
|
||||
```
|
||||
|
||||
다음과 같은 시크릿을 작성한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
password: MWYyZDFlMmU2N2Rm
|
||||
```
|
||||
|
||||
이제 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)를 사용하여 시크릿을 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./secret.yaml
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
secret "mysecret" created
|
||||
```
|
||||
|
||||
특정 시나리오의 경우, `stringData` 필드를 대신 사용할 수 있다. 이
|
||||
필드를 사용하면 base64로 인코딩되지 않은 문자열을 시크릿에 직접 넣을 수 있으며,
|
||||
시크릿이 생성되거나 업데이트될 때 문자열이 인코딩된다.
|
||||
|
||||
이에 대한 실질적인 예는 애플리케이션 배포 시에
|
||||
구성 파일 저장을 위해서 시크릿을 사용하되, 배포 프로세스 중에 해당 구성 파일의
|
||||
일부를 채우려는 경우이다.
|
||||
|
||||
예를 들어, 애플리케이션이 다음 구성 파일을 사용하는 경우,
|
||||
|
||||
```yaml
|
||||
apiUrl: "https://my.api.com/api/v1"
|
||||
username: "user"
|
||||
password: "password"
|
||||
```
|
||||
|
||||
다음 정의를 사용하여 이를 시크릿에 저장할 수 있다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
stringData:
|
||||
config.yaml: |-
|
||||
apiUrl: "https://my.api.com/api/v1"
|
||||
username: {{username}}
|
||||
password: {{password}}
|
||||
```
|
||||
|
||||
그런 다음 `kubectl apply` 를 실행하기 전에 배포 도구로
|
||||
`{{username}}` 및 `{{password}}` 템플릿 변수를 바꿀 수 있다.
|
||||
|
||||
`stringData` 필드는 쓰기 전용의 편의 필드이다. 이 내용은 시크릿을
|
||||
검색할 때 출력되지 않는다. 예를 들어, 다음 명령을 실행해본다.
|
||||
|
||||
```shell
|
||||
kubectl get secret mysecret -o yaml
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
creationTimestamp: 2018-11-15T20:40:59Z
|
||||
name: mysecret
|
||||
namespace: default
|
||||
resourceVersion: "7225"
|
||||
uid: c280ad2e-e916-11e8-98f2-025000000001
|
||||
type: Opaque
|
||||
data:
|
||||
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
|
||||
```
|
||||
|
||||
`username` 과 같은 필드가 `data` 와 `stringData` 모두에 지정되면,
|
||||
`stringData` 의 값이 사용된다. 예를 들어, 다음의 시크릿 정의를 보자.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
stringData:
|
||||
username: administrator
|
||||
```
|
||||
|
||||
아래의 시크릿에서 결과는 다음과 같다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
creationTimestamp: 2018-11-15T20:46:46Z
|
||||
name: mysecret
|
||||
namespace: default
|
||||
resourceVersion: "7579"
|
||||
uid: 91460ecb-e917-11e8-98f2-025000000001
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW5pc3RyYXRvcg==
|
||||
```
|
||||
|
||||
위의 `YWRtaW5pc3RyYXRvcg==` 를 디코딩하면 `administrator` 가 된다.
|
||||
|
||||
`data` 와 `stringData` 의 키는 영숫자,
|
||||
'-', '_' 또는 '.'로 구성되어야 한다.
|
||||
|
||||
{{< note >}}
|
||||
시크릿 데이터의 직렬화된 JSON 및 YAML 값은
|
||||
base64 문자열로 인코딩된다. 줄바꿈은 이러한 문자열 내에서 유효하지 않으므로
|
||||
생략해야 한다. Darwin/macOS에서 `base64` 유틸리티를 사용할 때,
|
||||
사용자는 긴 라인을 분할하는 `-b` 옵션을 사용하면 안된다. 반대로, 리눅스 사용자는
|
||||
`-w` 옵션을 사용할 수 없는 경우 `base64` 명령이나 `base64 | tr -d '\n'` 파이프라인에
|
||||
`-w 0` 옵션을 추가 *해야 한다*.
|
||||
{{< /note >}}
|
||||
|
||||
#### 생성기를 통해 시크릿 생성하기
|
||||
|
||||
쿠버네티스 v1.14부터 `kubectl` 은 [Kustomize를 사용한 오브젝트 관리](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)를 지원한다. Kustomize는 시크릿과 컨피그맵(ConfigMap)을 생성하기 위한
|
||||
리소스 생성기를 제공한다. Kustomize 생성기는 디렉터리 내의
|
||||
`kustomization.yaml` 파일에 지정되어야 한다. 시크릿을 생성한 후,
|
||||
`kubectl apply` 를 사용하여 API 서버에서 시크릿을 만들 수 있다.
|
||||
|
||||
#### 파일을 통해 시크릿 생성하기
|
||||
|
||||
./username.txt 와 ./password.txt 파일에서
|
||||
`secretGenerator` 를 정의하여 시크릿을 생성할 수 있다.
|
||||
|
||||
```shell
|
||||
cat <<EOF >./kustomization.yaml
|
||||
secretGenerator:
|
||||
- name: db-user-pass
|
||||
files:
|
||||
- username.txt
|
||||
- password.txt
|
||||
EOF
|
||||
```
|
||||
|
||||
`kustomization.yaml` 을 포함하는 디렉터리를 적용하여 시크릿을 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -k .
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
secret/db-user-pass-96mffmfh4k created
|
||||
```
|
||||
|
||||
시크릿이 생성되었는지 다음의 명령으로 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get secrets
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
db-user-pass-96mffmfh4k Opaque 2 51s
|
||||
```
|
||||
|
||||
시크릿에 대한 설명을 볼 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl describe secrets/db-user-pass-96mffmfh4k
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
Name: db-user-pass
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
password.txt: 12 bytes
|
||||
username.txt: 5 bytes
|
||||
```
|
||||
|
||||
#### 문자열 리터럴(literals)을 통해 시크릿 생성하기
|
||||
|
||||
문자열 리터럴인 `username=admin` 과 `password=secret` 을
|
||||
`secretGenerator` 에 정의하여 시크릿을 만들 수 있다.
|
||||
|
||||
```shell
|
||||
cat <<EOF >./kustomization.yaml
|
||||
secretGenerator:
|
||||
- name: db-user-pass
|
||||
literals:
|
||||
- username=admin
|
||||
- password=secret
|
||||
EOF
|
||||
```
|
||||
|
||||
`kustomization.yaml` 을 포함하는 디렉터리를 적용하여 시크릿을 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -k .
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
secret/db-user-pass-dddghtt9b5 created
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
시크릿이 생성될 때, 시크릿의 이름은 시크릿 데이터를
|
||||
해시하고, 해시된 값을 이름에 추가하는 방식으로 만들어진다. 이 방식은
|
||||
데이터가 수정될 때마다 새로운 시크릿이 생성되도록 만든다.
|
||||
{{< /note >}}
|
||||
|
||||
#### 시크릿 디코딩하기
|
||||
|
||||
`kubectl get secret` 을 실행하여 시크릿을 검색할 수 있다.
|
||||
예를 들어, 다음 명령을 실행하여 이전 섹션에서
|
||||
생성된 시크릿을 볼 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get secret mysecret -o yaml
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
creationTimestamp: 2016-01-22T18:41:56Z
|
||||
name: mysecret
|
||||
namespace: default
|
||||
resourceVersion: "164619"
|
||||
uid: cfee02d6-c137-11e5-8d73-42010af00002
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
password: MWYyZDFlMmU2N2Rm
|
||||
```
|
||||
|
||||
`password` 필드를 디코딩한다.
|
||||
|
||||
```shell
|
||||
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
#### 시크릿 편집하기
|
||||
### 시크릿 편집하기
|
||||
|
||||
기존 시크릿은 다음 명령을 사용하여 편집할 수 있다.
|
||||
|
||||
|
|
@ -1273,3 +893,10 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
|
|||
API 서버에서 _모든_ 시크릿을 읽을 수 있다. 단일 노드에 대한 루트 취약점 공격의
|
||||
영향을 제한하기 위해, 실제로 필요한 노드에만 시크릿을 보내는 것이 앞으로 계획된
|
||||
기능이다.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [`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/)하는 방법 배우기
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ handler: myconfiguration # 상응하는 CRI 설정의 이름임
|
|||
{{< note >}}
|
||||
런타임클래스 쓰기 작업(create/update/patch/delete)은
|
||||
클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다.
|
||||
더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
|
||||
더 자세한 정보는 [권한 개요](/ko/docs/reference/access-authn-authz/authorization/)를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 사용
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
|
|||
|
||||
### API 접근 익스텐션
|
||||
|
||||
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
|
||||
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
|
||||
|
||||
이러한 각 단계는 익스텐션 포인트를 제공한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -253,6 +253,6 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
|
|||
* 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기
|
||||
* 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기
|
||||
* 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기
|
||||
* [토폴로지 관리자](/docs/tasks/adminster-cluster/topology-manager/)에 대해 알아보기
|
||||
* [토폴로지 관리자](/docs/tasks/administer-cluster/topology-manager/)에 대해 알아보기
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -127,7 +127,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
|
|||
|
||||
### API 접근 익스텐션
|
||||
|
||||
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
|
||||
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
|
||||
|
||||
이러한 각 단계는 익스텐션 포인트를 제공한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: 쿠버네티스 API
|
|||
content_type: concept
|
||||
weight: 30
|
||||
description: >
|
||||
쿠버네티스 API를 사용하면 쿠버네티스 오브젝트들의 상태를 쿼리하고 조작할 수 있다.
|
||||
쿠버네티스 API를 사용하면 쿠버네티스 오브젝트들의 상태를 쿼리하고 조작할 수 있다.
|
||||
쿠버네티스 컨트롤 플레인의 핵심은 API 서버와 그것이 노출하는 HTTP API이다. 사용자와 클러스터의 다른 부분 및 모든 외부 컴포넌트는 API 서버를 통해 서로 통신한다.
|
||||
card:
|
||||
name: concepts
|
||||
|
|
@ -20,24 +20,17 @@ card:
|
|||
쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예:
|
||||
파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다.
|
||||
|
||||
API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/ko/docs/reference)에 기술되어 있다.
|
||||
대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/)
|
||||
커맨드 라인 인터페이스 또는 API를 사용하는
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과
|
||||
같은 다른 커맨드 라인 도구를 통해 수행할 수 있다.
|
||||
그러나, REST 호출을 사용하여 API에 직접 접근할 수도 있다.
|
||||
|
||||
쿠버네티스 API를 사용하여 애플리케이션을 작성하는 경우
|
||||
[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이 좋다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## API 변경
|
||||
|
||||
새로운 유스케이스가 등장하거나 기존 시스템이 변경됨에 따라 성공적인 시스템은 성장하고 변경될 필요가 있다.
|
||||
따라서, 쿠버네티스는 쿠버네티스 API를 지속적으로 변경하고 성장시킬 수 있는 디자인 기능을 가지고 있다.
|
||||
쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 중단하지 _않고_,
|
||||
다른 프로젝트가 적응할 수 있도록 오랫동안 호환성을 유지하는 것을 목표로 한다.
|
||||
|
||||
일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다.
|
||||
리소스나 필드를 없애는 일은 다음의
|
||||
[API 사용 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따른다.
|
||||
|
||||
호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은
|
||||
[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)을 참고한다.
|
||||
|
||||
## OpenAPI 명세 {#api-specification}
|
||||
|
||||
완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다.
|
||||
|
|
@ -76,96 +69,58 @@ OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
|
|||
<caption>Valid request header values for OpenAPI v2 queries</caption>
|
||||
</table>
|
||||
|
||||
쿠버네티스는 주로 클러스터 내부 통신용 API를 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다. 해당 API는 [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 문서와 IDL 파일에 문서화되어 있고 각각의 스키마를 담고 있는 IDL 파일은 API 오브젝트를 정의하는 Go 패키지에 들어있다.
|
||||
쿠버네티스는 주로 클러스터 내부 통신을 위해 대안적인
|
||||
Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
|
||||
자세한 내용은 [쿠버네티스 Protobuf 직렬화](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 디자인 제안과
|
||||
API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
|
||||
IDL(인터페이스 정의 언어) 파일을 참고한다.
|
||||
|
||||
## API 버전 규칙
|
||||
## API 변경 사항
|
||||
|
||||
필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
|
||||
쿠버네티스는 `/api/v1`이나 `/apis/rbac.authorization.k8s.io/v1alpha1`과 같이
|
||||
각각 다른 API 경로에서 복수의 API 버전을 지원한다.
|
||||
성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다.
|
||||
따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 기능을 설계했다.
|
||||
쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 _않고_ 다른 프로젝트가
|
||||
적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.
|
||||
|
||||
버전 관리는 API가 시스템 리소스와 동작에 대해 명확하고 일관된 보기를
|
||||
제공하고 수명 종료(end-of-life)와 실험적인 API에 대한 접근을 제어할 수 있도록
|
||||
리소스 또는 필드 수준이 아닌 API 수준에서 수행된다.
|
||||
일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다.
|
||||
리소스 또는 필드를 제거하려면
|
||||
[API 지원 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따라야 한다.
|
||||
|
||||
JSON과 Protobuf 직렬화 스키마는 스키마 변경에 대한 동일한 지침을 따르며 아래의 모든 설명은 두 형식을 모두 포함한다.
|
||||
호환 가능한 변경 사항과 API 변경 방법은
|
||||
[API 변경 사항](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)에 자세히 설명되어 있다.
|
||||
|
||||
참고로 API 버전 관리와 소프트웨어 버전 관리는 간접적으로만 연관이 있다.
|
||||
[쿠버네티스 릴리스 버전 관리](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
|
||||
제안은 API 버전 관리와 소프트웨어 버전 관리 사이의 관계를 설명한다.
|
||||
## API 그룹과 버전 규칙
|
||||
|
||||
API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은
|
||||
[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서
|
||||
상세히 다룬다. 요약하자면 다음과 같다.
|
||||
필드를 쉽게 제거하거나 리소스 표현을 재구성하기 위해,
|
||||
쿠버네티스는 각각 `/api/v1` 또는 `/apis/rbac.authorization.k8s.io/v1alpha1` 과
|
||||
같은 서로 다른 API 경로에서 여러 API 버전을 지원한다.
|
||||
|
||||
- 알파(Alpha) 수준:
|
||||
- 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
|
||||
- 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다. 기본적으로 비활성화되어 있다.
|
||||
- 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
|
||||
- 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
|
||||
- 버그의 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
|
||||
- 베타(Beta) 수준:
|
||||
- 버전 이름에 `beta`가 포함된다. (예: `v2beta3`).
|
||||
- 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. 기본적으로 활성화되어 있다.
|
||||
- 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
|
||||
- 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우,
|
||||
다음 버전으로 이관할 수 있는 가이드를 제공할 것이다.
|
||||
이 때 API 오브젝트의 삭제, 편집 또는 재생성이 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
|
||||
- 다음 릴리스에서 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다.
|
||||
복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면 이런 제약에서 안심이 될 수도 있겠다.
|
||||
- **베타 기능을 사용하고 피드백을 주기를 바란다! 일단 베타가 끝나면, 실질적으로 더 많은 변경이 어렵다.**
|
||||
- 안정화(stable) 수준:
|
||||
- 버전 이름이 `vX`이고 `X` 는 정수다.
|
||||
- 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다.
|
||||
버전 규칙은 리소스나 필드 수준이 아닌 API 수준에서 수행되어
|
||||
API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를 제공하고
|
||||
수명 종료 및/또는 실험적 API에 대한 접근을
|
||||
제어할 수 있도록 한다.
|
||||
|
||||
## API 그룹
|
||||
API 버전 수준 정의에 대한 자세한 내용은
|
||||
[API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다.
|
||||
|
||||
쿠버네티스 API를 보다 쉽게 확장하기 위해서, [*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다.
|
||||
API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다.
|
||||
보다 쉽게 발전하고 API를 확장하기 위해, 쿠버네티스는
|
||||
[활성화 또는 비활성화](/ko/docs/reference/using-api/api-overview/#api-그룹-활성화-또는-비활성화-하기)가
|
||||
가능한 [API 그룹](/ko/docs/reference/using-api/api-overview/#api-그룹)을 구현한다.
|
||||
|
||||
클러스터에 다양한 API 그룹이 있다.
|
||||
## API 확장
|
||||
|
||||
1. *레거시* 그룹이라고도 하는 *핵심* 그룹은 REST 경로인 `/api/v1/` 에 있고, `apiVersion: v1`을 사용한다.
|
||||
|
||||
1. 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다
|
||||
(예: `apiVersion: batch/v1`). 사용 가능한 API 그룹의 전체의 목록은
|
||||
[쿠버네티스 API 참조](/ko/docs/reference/)에 있다.
|
||||
|
||||
|
||||
[사용자 지정 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)로 API를 확장하는 두 가지 방법이 있다.
|
||||
|
||||
1. [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)은
|
||||
API 서버가 선택한 리소스 API를 제공하는 방법을 선언적으로 정의할 수 있다.
|
||||
1. 또한, [자신의 확장 API 서버 구현](/ko/docs/tasks/extend-kubernetes/setup-extension-api-server/)과
|
||||
[aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를
|
||||
사용해서 클라이언트를 원활하게 만들 수 있다.
|
||||
|
||||
|
||||
## API 그룹 활성화 또는 비활성화하기
|
||||
|
||||
특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. kube-apiserver에서 커맨드 라인 옵션으로 `--runtime-config` 를
|
||||
설정해서 활성화하거나 비활성화할 수 있다.
|
||||
|
||||
`--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화시키려면,
|
||||
`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화시키려면, `--runtime-config=batch/v2alpha1`을
|
||||
설정한다. 이 플래그는 API 서버의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
|
||||
|
||||
{{< note >}}그룹이나 리소스를 활성화 또는 비활성화하려면 kube-apiserver와
|
||||
controller-manager를 재시작해서 `--runtime-config` 변경 사항을 반영해야 한다. {{< /note >}}
|
||||
|
||||
## 지속성
|
||||
|
||||
쿠버네티스는 API 리소스에 대한 직렬화된 상태를 {{< glossary_tooltip term_id="etcd" >}}에
|
||||
기록하고 저장한다.
|
||||
쿠버네티스 API는 다음 두 가지 방법 중 하나로 확장할 수 있다.
|
||||
|
||||
1. [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를
|
||||
사용하면 API 서버가 선택한 리소스 API를 제공하는 방법을 선언적으로 정의할 수 있다.
|
||||
1. [애그리게이션 레이어(aggregation layer)](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를
|
||||
구현하여 쿠버네티스 API를 확장할 수도 있다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)는 클러스터가
|
||||
API 접근에 대한 인증과 권한을 관리하는 방법을 설명한다.
|
||||
|
||||
전체 API 규약은
|
||||
[API 규약](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)
|
||||
문서에 설명되어 있다.
|
||||
|
||||
API 엔드포인트, 리소스 타입과 샘플은 [API 참조](/docs/reference/kubernetes-api/)에 설명되어 있다.
|
||||
- 자체 [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)을
|
||||
추가하여 쿠버네티스 API를 확장하는 방법에 대해 배우기.
|
||||
- [API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)는
|
||||
클러스터가 API 접근을 위한 인증 및 권한을 관리하는 방법을 설명한다.
|
||||
- [API 레퍼런스](/docs/reference/kubernetes-api/)를
|
||||
읽고 API 엔드포인트, 리소스 유형 및 샘플에 대해 배우기.
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ weight: 50
|
|||
|
||||
## 문법과 캐릭터 셋
|
||||
|
||||
_어노테이션_ 은 키/값 쌍이다. 유효한 어노테이션 키에는 두 개의 세그먼트가 있다. 두 개의 세그먼트는 선택적인 접두사와 이름(name)이며, 슬래시(`/`)로 구분된다. 이름 세그먼트는 필수이며, 영문 숫자(`[a-z0-9A-Z]`)로 시작하고 끝나는 63자 이하이어야 하고, 사이에 대시(`-`), 밑줄(`_`), 점(`.`)이 들어갈 수 있다. 접두사는 선택적이다. 지정된 경우, 접두사는 DNS 하위 도메인이어야 한다. 점(`.`)으로 구분된 일련의 DNS 레이블은 총 253자를 넘지 않고, 뒤에 슬래시(`/`)가 붙는다.
|
||||
_어노테이션_ 은 키/값 쌍이다. 유효한 어노테이션 키에는 두 개의 세그먼트가 있다. 두 개의 세그먼트는 선택적인 접두사와 이름(name)이며, 슬래시(`/`)로 구분된다. 이름 세그먼트는 필수이며, 영문 숫자(`[a-z0-9A-Z]`)로 시작하고 끝나는 63자 이하이어야 하고, 사이에 대시(`-`), 밑줄(`_`), 점(`.`)이 들어갈 수 있다. 접두사는 선택적이다. 지정된 경우, 접두사는 DNS 서브도메인이어야 한다. 점(`.`)으로 구분된 일련의 DNS 레이블은 총 253자를 넘지 않고, 뒤에 슬래시(`/`)가 붙는다.
|
||||
|
||||
접두사가 생략되면, 어노테이션 키는 사용자에게 비공개로 간주된다. 최종 사용자 오브젝트에 어노테이션을 추가하는 자동화된 시스템 구성 요소(예 :`kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, 또는 다른 써드파티 자동화)는 접두사를 지정해야 한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -58,15 +58,15 @@ metadata:
|
|||
|
||||
## 애플리케이션과 애플리케이션 인스턴스
|
||||
|
||||
애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에
|
||||
한번 또는 그 이상 설치할 수 있다. 예를 들어 워드프레스는 다른 워드프레스가
|
||||
설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다.
|
||||
애플리케이션은 동일한 쿠버네티스 클러스터에,
|
||||
심지어는 동일한 네임스페이스에도 한번 또는 그 이상 설치될 수 있다. 예를 들어, 하나의 쿠버네티스 클러스터에
|
||||
워드프레스가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.
|
||||
|
||||
애플리케이션의 이름과 인스턴스 이름은 별도로 기록된다.
|
||||
예를 들어 워드프레스는 `app.kubernetes.io/name` 에 `wordpress` 를 가지며 인스턴스 이름으로는
|
||||
`app.kubernetes.io/instance` 에 `wordpress-abcxzy` 의 값을 가진다.
|
||||
이를 통해 애플리케이션과 애플리케이션 인스턴스를 식별할 수 있다.
|
||||
모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.
|
||||
애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다.
|
||||
예를 들어 워드프레스는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며,
|
||||
애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에
|
||||
`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를
|
||||
식별할 수 있다. 모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.
|
||||
|
||||
## 예시
|
||||
|
||||
|
|
@ -170,4 +170,3 @@ metadata:
|
|||
|
||||
MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ RBAC 바인딩에 대한 자세한 예는,
|
|||
### 문제 해결
|
||||
|
||||
- [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)는
|
||||
[보안 API 포트](/docs/reference/access-authn-authz/controlling-access/)에 대해 실행해야 하며,
|
||||
[보안 API 포트](/ko/docs/reference/access-authn-authz/controlling-access/)에 대해 실행해야 하며,
|
||||
슈퍼유저 권한이 없어야 한다. 그렇지 않으면 요청이 인증 및 권한 부여 모듈을 우회하고,
|
||||
모든 파드시큐리티폴리시 오브젝트가 허용되며
|
||||
사용자는 특권있는 컨테이너를 만들 수 있다. 컨트롤러 관리자 권한 구성에 대한 자세한
|
||||
|
|
|
|||
|
|
@ -206,6 +206,19 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
|
|||
|
||||
쿼터 스펙의 `scopeSelector`가 파드를 선택한 경우에만 쿼터가 일치하고 사용된다.
|
||||
|
||||
`scopeSelector` 필드를 사용하여 우선 순위 클래스의 쿼터 범위를 지정하면, 쿼터 오브젝트는 다음의 리소스만 추적하도록 제한된다.
|
||||
|
||||
* `pods`
|
||||
* `cpu`
|
||||
* `memory`
|
||||
* `ephemeral-storage`
|
||||
* `limits.cpu`
|
||||
* `limits.memory`
|
||||
* `limits.ephemeral-storage`
|
||||
* `requests.cpu`
|
||||
* `requests.memory`
|
||||
* `requests.ephemeral-storage`
|
||||
|
||||
이 예에서는 쿼터 오브젝트를 생성하여 특정 우선 순위의 파드와 일치시킨다.
|
||||
예제는 다음과 같이 작동한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -69,17 +69,7 @@ spec:
|
|||
## 넘어가기 전에: 내장 노드 레이블들 {#built-in-node-labels}
|
||||
|
||||
[붙인](#1-단계-노드에-레이블-붙이기) 레이블뿐만 아니라, 노드에는
|
||||
표준 레이블 셋이 미리 채워져 있다. 이 레이블들은 다음과 같다.
|
||||
|
||||
* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
|
||||
* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
|
||||
* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
|
||||
* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
|
||||
* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
|
||||
* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
|
||||
* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
|
||||
* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
|
||||
* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
|
||||
표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/docs/reference/kubernetes-api/labels-annotations-taints/)를 참고한다.
|
||||
|
||||
{{< note >}}
|
||||
이 레이블들의 값은 클라우드 공급자에 따라 다르고 신뢰성이 보장되지 않는다.
|
||||
|
|
|
|||
|
|
@ -48,17 +48,10 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
|
|||
이를 변경한 후에 다음을 실행해서
|
||||
|
||||
```bash
|
||||
kubectl get componentstatuses
|
||||
kubectl get pods -n kube-system | grep kube-scheduler
|
||||
```
|
||||
|
||||
kube-scheduler 컴포넌트가 정상인지 확인할 수 있다. 출력은 다음과 유사하다.
|
||||
|
||||
```
|
||||
NAME STATUS MESSAGE ERROR
|
||||
controller-manager Healthy ok
|
||||
scheduler Healthy ok
|
||||
...
|
||||
```
|
||||
kube-scheduler 컴포넌트가 정상인지 확인할 수 있다.
|
||||
|
||||
## 노드 스코어링(scoring) 임계값 {#percentage-of-nodes-to-score}
|
||||
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리
|
|||
* [파드 보안 표준](/docs/concepts/security/pod-security-standards/)
|
||||
* [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/)
|
||||
* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)
|
||||
* [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/)
|
||||
* [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/)
|
||||
|
|
|
|||
|
|
@ -21,8 +21,8 @@ _엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워
|
|||
|
||||
엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
|
||||
간단하고 직접적인 방법을 제공한다. 불행하게도 쿠버네티스 클러스터와
|
||||
{{< glossary_tooltip text="서비스" term_id="service" >}}가 점점 더
|
||||
커짐에 따라, 이 API의 한계가 더욱 눈에 띄게
|
||||
{{< glossary_tooltip text="서비스" term_id="service" >}}가 더 많은 수의 백엔드 파드로
|
||||
더 많은 트래픽을 처리하고 전송하는 방향으로 성장함에 따라, 이 API의 한계가 더욱 눈에 띄게
|
||||
되었다.
|
||||
특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에
|
||||
어려움이 있었다.
|
||||
|
|
|
|||
|
|
@ -27,15 +27,26 @@ weight: 40
|
|||
{{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
|
||||
트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.
|
||||
|
||||
```none
|
||||
internet
|
||||
|
|
||||
[ Ingress ]
|
||||
--|-----|--
|
||||
[ Services ]
|
||||
```
|
||||
다음은 인그레스가 모든 트래픽을 하나의 서비스로 보내는 간단한 예시이다.
|
||||
{{< mermaid >}}
|
||||
graph LR;
|
||||
client([클라이언트])-. 인그레스-매니지드 <br> 로드 밸런서 .->ingress[인그레스];
|
||||
ingress-->|라우팅 규칙|service[서비스];
|
||||
subgraph 클러스터
|
||||
ingress;
|
||||
service-->pod1[파드];
|
||||
service-->pod2[파드];
|
||||
end
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class ingress,service,pod1,pod2 k8s;
|
||||
class client plain;
|
||||
class cluster cluster;
|
||||
{{</ mermaid >}}
|
||||
|
||||
인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
|
||||
|
||||
인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
|
||||
|
||||
인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
|
||||
[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는
|
||||
|
|
@ -104,7 +115,7 @@ weight: 40
|
|||
|
||||
### 리소스 백엔드 {#resource-backend}
|
||||
|
||||
`Resource` 백엔드는 인그레스 오브젝트의 동일한 네임스페이스 내에 있는
|
||||
`Resource` 백엔드는 인그레스 오브젝트와 동일한 네임스페이스 내에 있는
|
||||
다른 쿠버네티스 리소스에 대한 ObjectRef이다. `Resource` 는 서비스와
|
||||
상호 배타적인 설정이며, 둘 다 지정하면 유효성 검사에 실패한다. `Resource`
|
||||
백엔드의 일반적인 용도는 정적 자산이 있는 오브젝트 스토리지 백엔드로 데이터를
|
||||
|
|
@ -272,10 +283,25 @@ test-ingress external-lb * 203.0.113.123 80 59s
|
|||
트래픽을 라우팅 한다. 인그레스를 사용하면 로드 밸런서의 수를
|
||||
최소로 유지할 수 있다. 예를 들어 다음과 같은 설정을 한다.
|
||||
|
||||
```
|
||||
foo.bar.com -> 178.91.123.132 -> / foo service1:4200
|
||||
/ bar service2:8080
|
||||
```
|
||||
{{< mermaid >}}
|
||||
graph LR;
|
||||
client([클라이언트])-. 인그레스-매니지드 <br> 로드 밸런서 .->ingress[인그레스, 178.91.123.132];
|
||||
ingress-->|/foo|service1[서비스 service1:4200];
|
||||
ingress-->|/bar|service2[서비스 service2:8080];
|
||||
subgraph 클러스터
|
||||
ingress;
|
||||
service1-->pod1[파드];
|
||||
service1-->pod2[파드];
|
||||
service2-->pod3[파드];
|
||||
service2-->pod4[파드];
|
||||
end
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
|
||||
class client plain;
|
||||
class cluster cluster;
|
||||
{{</ mermaid >}}
|
||||
|
||||
다음과 같은 인그레스가 필요하다.
|
||||
|
||||
|
|
@ -319,11 +345,26 @@ Events:
|
|||
|
||||
이름 기반의 가상 호스트는 동일한 IP 주소에서 여러 호스트 이름으로 HTTP 트래픽을 라우팅하는 것을 지원한다.
|
||||
|
||||
```none
|
||||
foo.bar.com --| |-> foo.bar.com service1:80
|
||||
| 178.91.123.132 |
|
||||
bar.foo.com --| |-> bar.foo.com service2:80
|
||||
```
|
||||
{{< mermaid >}}
|
||||
graph LR;
|
||||
client([클라이언트])-. 인그레스-매니지드 <br> 로드 밸런서 .->ingress[인그레스, 178.91.123.132];
|
||||
ingress-->|호스트: foo.bar.com|service1[서비스 service1:80];
|
||||
ingress-->|호스트: bar.foo.com|service2[서비스 service2:80];
|
||||
subgraph 클러스터
|
||||
ingress;
|
||||
service1-->pod1[파드];
|
||||
service1-->pod2[파드];
|
||||
service2-->pod3[파드];
|
||||
service2-->pod4[파드];
|
||||
end
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
|
||||
class client plain;
|
||||
class cluster cluster;
|
||||
{{</ mermaid >}}
|
||||
|
||||
|
||||
다음 인그레스는 [호스트 헤더](https://tools.ietf.org/html/rfc7230#section-5.4)에 기반한 요청을
|
||||
라우팅 하기 위해 뒷단의 로드 밸런서를 알려준다.
|
||||
|
|
|
|||
|
|
@ -22,8 +22,8 @@ weight: 10
|
|||
|
||||
## 동기
|
||||
|
||||
쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 수명이 있다.
|
||||
파드는 생성되고, 소멸된 후 부활하지 않는다.
|
||||
쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 상태와
|
||||
일치하도록 생성되고 삭제된다. 파드는 비영구적 리소스이다.
|
||||
만약 앱을 실행하기 위해 {{< glossary_tooltip term_id="deployment" text="디플로이먼트" >}}를 사용한다면,
|
||||
동적으로 파드를 생성하고 제거할 수 있다.
|
||||
|
||||
|
|
@ -44,8 +44,8 @@ _서비스_ 로 들어가보자.
|
|||
정책을 정의하는 추상적 개념이다. (때로는 이 패턴을
|
||||
마이크로-서비스라고 한다.) 서비스가 대상으로 하는 파드 집합은 일반적으로
|
||||
{{< glossary_tooltip text="셀렉터" term_id="selector" >}}가 결정한다.
|
||||
(셀렉터가 _없는_ 서비스가 필요한 이유는 [아래](#셀렉터가-없는-서비스)를
|
||||
참조한다).
|
||||
서비스 엔드포인트를 정의하는 다른 방법에 대한 자세한 내용은
|
||||
[셀렉터가 _없는_ 서비스](#셀렉터가-없는-서비스)를 참고한다.
|
||||
|
||||
예를 들어, 3개의 레플리카로 실행되는 스테이트리스 이미지-처리 백엔드를
|
||||
생각해보자. 이러한 레플리카는 대체 가능하다. 즉, 프론트엔드는 그것들이 사용하는 백엔드를
|
||||
|
|
@ -127,12 +127,12 @@ spec:
|
|||
다른 종류의 백엔드를 추상화할 수도 있다.
|
||||
예를 들면
|
||||
|
||||
* 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만,
|
||||
테스트 환경에서는 자체 데이터베이스를 사용한다.
|
||||
* 한 서비스에서 다른
|
||||
{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 또는 다른 클러스터의 서비스를 지정하려고 한다.
|
||||
* 워크로드를 쿠버네티스로 마이그레이션하고 있다. 해당 방식을 평가하는 동안,
|
||||
쿠버네티스에서는 일정 비율의 백엔드만 실행한다.
|
||||
* 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만,
|
||||
테스트 환경에서는 자체 데이터베이스를 사용한다.
|
||||
* 한 서비스에서 다른
|
||||
{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 또는 다른 클러스터의 서비스를 지정하려고 한다.
|
||||
* 워크로드를 쿠버네티스로 마이그레이션하고 있다. 해당 방식을 평가하는 동안,
|
||||
쿠버네티스에서는 일정 비율의 백엔드만 실행한다.
|
||||
|
||||
이러한 시나리오 중에서 파드 셀렉터 _없이_ 서비스를 정의 할 수 있다.
|
||||
예를 들면
|
||||
|
|
@ -150,7 +150,7 @@ spec:
|
|||
```
|
||||
|
||||
이 서비스에는 셀렉터가 없으므로, 해당 엔드포인트 오브젝트가 자동으로
|
||||
생성되지 *않는다*. 엔드포인트 오브젝트를 수동으로 추가하여, 서비스를 실행 중인 네트워크 주소 및 포트에
|
||||
생성되지 않는다. 엔드포인트 오브젝트를 수동으로 추가하여, 서비스를 실행 중인 네트워크 주소 및 포트에
|
||||
서비스를 수동으로 매핑할 수 있다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -186,6 +186,7 @@ DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내
|
|||
이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
|
||||
|
||||
### 엔드포인트슬라이스
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
||||
|
||||
엔드포인트슬라이스는 엔드포인트에 보다 확장 가능한 대안을 제공할 수 있는
|
||||
|
|
@ -202,9 +203,8 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만,
|
|||
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
AppProtocol 필드는 각 서비스 포트에 사용될 애플리케이션 프로토콜을
|
||||
지정하는 방법을 제공한다. 이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스에
|
||||
의해 미러링된다.
|
||||
`AppProtocol` 필드는 각 서비스 포트에 대한 애플리케이션 프로토콜을 지정하는 방법을 제공한다.
|
||||
이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스 리소스에 의해 미러링된다.
|
||||
|
||||
## 가상 IP와 서비스 프록시
|
||||
|
||||
|
|
@ -222,20 +222,19 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
|
|||
|
||||
서비스에 프록시를 사용하는 데는 몇 가지 이유가 있다.
|
||||
|
||||
* 레코드 TTL을 고려하지 않고, 만료된 이름 검색 결과를
|
||||
캐싱하는 DNS 구현에 대한 오래된 역사가 있다.
|
||||
* 일부 앱은 DNS 검색을 한 번만 수행하고 결과를 무기한으로 캐시한다.
|
||||
* 앱과 라이브러리가 적절히 재-확인을 했다고 하더라도, DNS 레코드의 TTL이
|
||||
낮거나 0이면 DNS에 부하가 높아 관리하기가
|
||||
어려워 질 수 있다.
|
||||
* 레코드 TTL을 고려하지 않고, 만료된 이름 검색 결과를
|
||||
캐싱하는 DNS 구현에 대한 오래된 역사가 있다.
|
||||
* 일부 앱은 DNS 검색을 한 번만 수행하고 결과를 무기한으로 캐시한다.
|
||||
* 앱과 라이브러리가 적절히 재-확인을 했다고 하더라도, DNS 레코드의 TTL이
|
||||
낮거나 0이면 DNS에 부하가 높아 관리하기가
|
||||
어려워 질 수 있다.
|
||||
|
||||
### 유저 스페이스(User space) 프록시 모드 {#proxy-mode-userspace}
|
||||
|
||||
이 모드에서는, kube-proxy는 쿠버네티스 마스터의 서비스, 엔드포인트 오브젝트의
|
||||
추가와 제거를 감시한다. 각 서비스는 로컬 노드에서
|
||||
포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든
|
||||
연결은 (엔드포인트를 통해 보고된대로) 서비스의 백엔드 파드 중 하나로
|
||||
프록시된다.
|
||||
연결은 (엔드포인트를 통해 보고된대로) 서비스의 백엔드 파드 중 하나로 프록시된다.
|
||||
kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의
|
||||
`SessionAffinity` 설정을 고려한다.
|
||||
|
||||
|
|
@ -296,12 +295,12 @@ IPVS 프록시 모드는 iptables 모드와 유사한 넷필터 후크 기능을
|
|||
IPVS는 트래픽을 백엔드 파드로 밸런싱하기 위한 추가 옵션을 제공한다.
|
||||
다음과 같다.
|
||||
|
||||
- `rr`: 라운드-로빈
|
||||
- `lc`: 최소 연결 (가장 적은 수의 열려있는 연결)
|
||||
- `dh`: 목적지 해싱
|
||||
- `sh`: 소스 해싱
|
||||
- `sed`: 최단 예상 지연 (shortest expected delay)
|
||||
- `nq`: 큐 미사용 (never queue)
|
||||
* `rr`: 라운드-로빈
|
||||
* `lc`: 최소 연결 (가장 적은 수의 열려있는 연결)
|
||||
* `dh`: 목적지 해싱
|
||||
* `sh`: 소스 해싱
|
||||
* `sed`: 최단 예상 지연 (shortest expected delay)
|
||||
* `nq`: 큐 미사용 (never queue)
|
||||
|
||||
{{< note >}}
|
||||
IPVS 모드에서 kube-proxy를 실행하려면, kube-proxy를 시작하기 전에 노드에서 IPVS를
|
||||
|
|
@ -388,7 +387,7 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
|
|||
이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.
|
||||
|
||||
예를 들어, TCP 포트 6379를 개방하고
|
||||
클러스터 IP 주소 10.0.0.11이 할당된 서비스 `"redis-master"`는,
|
||||
클러스터 IP 주소 10.0.0.11이 할당된 서비스 `redis-master`는,
|
||||
다음 환경 변수를 생성한다.
|
||||
|
||||
```shell
|
||||
|
|
@ -421,18 +420,18 @@ CoreDNS와 같은, 클러스터-인식 DNS 서버는 새로운 서비스를 위
|
|||
모든 파드는 DNS 이름으로 서비스를 자동으로
|
||||
확인할 수 있어야 한다.
|
||||
|
||||
예를 들면, 쿠버네티스 네임스페이스 `"my-ns"`에 `"my-service"`라는
|
||||
예를 들면, 쿠버네티스 네임스페이스 `my-ns`에 `my-service`라는
|
||||
서비스가 있는 경우, 컨트롤 플레인과 DNS 서비스가 함께 작동하여
|
||||
`"my-service.my-ns"`에 대한 DNS 레코드를 만든다. `"my-ns"` 네임 스페이스의 파드들은
|
||||
`my-service.my-ns`에 대한 DNS 레코드를 만든다. `my-ns` 네임 스페이스의 파드들은
|
||||
간단히 `my-service`에 대한 이름 조회를 수행하여 찾을 수 있어야 한다
|
||||
(`"my-service.my-ns"` 역시 동작함).
|
||||
(`my-service.my-ns` 역시 동작함).
|
||||
|
||||
다른 네임스페이스의 파드들은 이름을 `my-service.my-ns`으로 사용해야 한다. 이 이름은
|
||||
서비스에 할당된 클러스터 IP로 변환된다.
|
||||
|
||||
쿠버네티스는 또한 알려진 포트에 대한 DNS SRV (서비스) 레코드를 지원한다.
|
||||
`"my-service.my-ns"` 서비스에 프로토콜이 `TCP`로 설정된 `"http"`라는 포트가 있는 경우,
|
||||
IP 주소와 `"http"`에 대한 포트 번호를 검색하기 위해 `_http._tcp.my-service.my-ns` 에 대한
|
||||
`my-service.my-ns` 서비스에 프로토콜이 `TCP`로 설정된 `http`라는 포트가 있는 경우,
|
||||
IP 주소와 `http`에 대한 포트 번호를 검색하기 위해 `_http._tcp.my-service.my-ns` 에 대한
|
||||
DNS SRV 쿼리를 수행할 수 있다.
|
||||
|
||||
쿠버네티스 DNS 서버는 `ExternalName` 서비스에 접근할 수 있는 유일한 방법이다.
|
||||
|
|
@ -465,9 +464,9 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
|
|||
`엔드포인트` 레코드를 생성하지 않는다. 그러나 DNS 시스템은 다음 중 하나를 찾고
|
||||
구성한다.
|
||||
|
||||
* [`ExternalName`](#externalname)-유형 서비스에 대한 CNAME 레코드
|
||||
* 다른 모든 유형에 대해, 서비스의 이름을 공유하는 모든 `엔드포인트`에
|
||||
대한 레코드
|
||||
* [`ExternalName`](#externalname)-유형 서비스에 대한 CNAME 레코드
|
||||
* 다른 모든 유형에 대해, 서비스의 이름을 공유하는 모든 `엔드포인트`에
|
||||
대한 레코드
|
||||
|
||||
## 서비스 퍼블리싱 (ServiceTypes) {#publishing-services-service-types}
|
||||
|
||||
|
|
@ -479,26 +478,26 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
|
|||
|
||||
`Type` 값과 그 동작은 다음과 같다.
|
||||
|
||||
* `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면
|
||||
클러스터 내에서만 서비스에 도달할 수 있다. 이것은
|
||||
`ServiceTypes`의 기본 값이다.
|
||||
* [`NodePort`](#nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를
|
||||
노출시킨다. `NodePort` 서비스가 라우팅되는 `ClusterIP` 서비스가
|
||||
자동으로 생성된다. `<NodeIP>:<NodePort>`를 요청하여,
|
||||
클러스터 외부에서
|
||||
`NodePort` 서비스에 접속할 수 있다.
|
||||
* [`LoadBalancer`](#loadbalancer): 클라우드 공급자의 로드 밸런서를 사용하여
|
||||
서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는
|
||||
`NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다.
|
||||
* [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를
|
||||
`externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에
|
||||
매핑한다.
|
||||
어떤 종류의 프록시도 설정되어 있지 않다.
|
||||
{{< note >}}
|
||||
`ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는 CoreDNS 버전 1.7 이상이 필요하다.
|
||||
{{< /note >}}
|
||||
* `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면
|
||||
클러스터 내에서만 서비스에 도달할 수 있다. 이것은
|
||||
`ServiceTypes`의 기본 값이다.
|
||||
* [`NodePort`](#nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를
|
||||
노출시킨다. `NodePort` 서비스가 라우팅되는 `ClusterIP` 서비스가
|
||||
자동으로 생성된다. `<NodeIP>:<NodePort>`를 요청하여,
|
||||
클러스터 외부에서
|
||||
`NodePort` 서비스에 접속할 수 있다.
|
||||
* [`LoadBalancer`](#loadbalancer): 클라우드 공급자의 로드 밸런서를 사용하여
|
||||
서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는
|
||||
`NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다.
|
||||
* [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를
|
||||
`externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에
|
||||
매핑한다. 어떤 종류의 프록시도 설정되어 있지 않다.
|
||||
{{< note >}}`ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는
|
||||
CoreDNS 버전 1.7 이상이 필요하다.
|
||||
{{< /note >}}
|
||||
|
||||
[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
|
||||
[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를
|
||||
노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
|
||||
|
||||
### NodePort 유형 {#nodeport}
|
||||
|
||||
|
|
@ -507,7 +506,6 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
|
|||
각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다.
|
||||
서비스는 할당된 포트를 `.spec.ports[*].nodePort` 필드에 나타낸다.
|
||||
|
||||
|
||||
포트를 프록시하기 위해 특정 IP를 지정하려면 kube-proxy의 `--nodeport-addresses` 플래그를 특정 IP 블록으로 설정할 수 있다. 이것은 쿠버네티스 v1.10부터 지원된다.
|
||||
이 플래그는 쉼표로 구분된 IP 블록 목록 (예: 10.0.0.0/8, 192.0.2.0/25)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
|
||||
|
||||
|
|
@ -528,6 +526,7 @@ NodePort를 사용하면 자유롭게 자체 로드 밸런싱 솔루션을 설
|
|||
`.spec.clusterIP:spec.ports[*].port`로 표기된다. (kube-proxy에서 `--nodeport-addresses` 플래그가 설정되면, <NodeIP>는 NodeIP를 필터링한다.)
|
||||
|
||||
예를 들면
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
|
|
@ -604,19 +603,21 @@ SCTP를 사용하는 경우, `LoadBalancer` 서비스 유형에 대한 아래의
|
|||
{{< /note >}}
|
||||
|
||||
#### 내부 로드 밸런서 {#internal-load-balancer}
|
||||
|
||||
혼재된 환경에서는 서비스의 트래픽을 동일한 (가상) 네트워크 주소 블록 내로
|
||||
라우팅해야하는 경우가 있다.
|
||||
라우팅해야 하는 경우가 있다.
|
||||
|
||||
수평 분할 DNS 환경에서는 외부와 내부 트래픽을 엔드포인트로 라우팅 할 수 있는 두 개의 서비스가 필요하다.
|
||||
|
||||
서비스에 다음 어노테이션 중 하나를 추가하여 이를 수행할 수 있다.
|
||||
추가할 어노테이션은 사용 중인 클라우드 서비스 공급자에 따라 다르다.
|
||||
내부 로드 밸런서를 설정하려면, 사용 중인 클라우드 서비스 공급자에 따라
|
||||
다음의 어노테이션 중 하나를 서비스에 추가한다.
|
||||
|
||||
{{< tabs name="service_tabs" >}}
|
||||
{{% tab name="Default" %}}
|
||||
탭 중 하나를 선택
|
||||
{{% /tab %}}
|
||||
{{% tab name="GCP" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
|
|
@ -625,8 +626,10 @@ metadata:
|
|||
cloud.google.com/load-balancer-type: "Internal"
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="AWS" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
|
|
@ -635,8 +638,10 @@ metadata:
|
|||
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Azure" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
|
|
@ -645,8 +650,10 @@ metadata:
|
|||
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="IBM Cloud" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
|
|
@ -655,8 +662,10 @@ metadata:
|
|||
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="OpenStack" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
|
|
@ -665,8 +674,10 @@ metadata:
|
|||
service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Baidu Cloud" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
|
|
@ -675,8 +686,10 @@ metadata:
|
|||
service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Tencent Cloud" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
|
|
@ -684,8 +697,10 @@ metadata:
|
|||
service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Alibaba Cloud" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
|
|
@ -693,10 +708,10 @@ metadata:
|
|||
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
#### AWS에서 TLS 지원 {#ssl-support-on-aws}
|
||||
|
||||
AWS에서 실행되는 클러스터에서 부분적으로 TLS / SSL을 지원하기 위해, `LoadBalancer` 서비스에 세 가지
|
||||
|
|
@ -821,7 +836,6 @@ Classic ELB의 연결 드레이닝은
|
|||
사용하여 인스턴스를 해제하기 전에,
|
||||
기존 연결을 열어 두는 목적으로 최대 시간을 초 단위로 설정할 수도 있다.
|
||||
|
||||
|
||||
```yaml
|
||||
metadata:
|
||||
name: my-service
|
||||
|
|
@ -989,6 +1003,7 @@ spec:
|
|||
type: ExternalName
|
||||
externalName: my.database.example.com
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다. IPv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은
|
||||
정식(canonical) DNS 이름을 지정하기 때문이다. IP 주소를 하드 코딩하려면,
|
||||
|
|
@ -1043,7 +1058,7 @@ spec:
|
|||
|
||||
## 단점
|
||||
|
||||
VIP용으로 유저스페이스 프록시를 사용하면, 중소 급 스케일에서는 동작하지만, 수천 개의
|
||||
VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일에서는 동작하지만, 수천 개의
|
||||
서비스가 포함된 대규모 클러스터로는 확장되지 않는다.
|
||||
[포털에 대한 독창적인 설계 제안](https://github.com/kubernetes/kubernetes/issues/1107)에 이에 대한 자세한 내용이
|
||||
있다.
|
||||
|
|
@ -1171,7 +1186,7 @@ IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이
|
|||
|
||||
{{< note >}}
|
||||
서비스 대신 {{< glossary_tooltip term_id="ingress" text="인그레스" >}} 를 사용하여
|
||||
HTTP / HTTPS 서비스를 노출할 수도 있다.
|
||||
HTTP/HTTPS 서비스를 노출할 수도 있다.
|
||||
{{< /note >}}
|
||||
|
||||
### PROXY 프로토콜
|
||||
|
|
@ -1187,6 +1202,7 @@ LoadBalancer 모드의 서비스를 사용하여 쿠버네티스 자체 외부
|
|||
```
|
||||
PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
|
||||
```
|
||||
|
||||
클라이언트 데이터가 뒤따라온다.
|
||||
|
||||
### SCTP
|
||||
|
|
@ -1225,11 +1241,8 @@ SCTP는 윈도우 기반 노드를 지원하지 않는다.
|
|||
kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다.
|
||||
{{< /warning >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기
|
||||
* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기
|
||||
* [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ _퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한
|
|||
|
||||
퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 단순히 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다.
|
||||
|
||||
[실습 예제와 함께 상세한 내용](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)을 참고하길 바란다.
|
||||
[실습 예제와 함께 상세한 내용](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)을 참고하길 바란다.
|
||||
|
||||
## 볼륨과 클레임 라이프사이클
|
||||
|
||||
|
|
@ -755,8 +755,8 @@ spec:
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [퍼시스턴트볼륨 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)에 대해 자세히 알아보기
|
||||
* [퍼시스턴트볼륨클레임 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)에 대해 자세히 알아보기
|
||||
* [퍼시스턴트볼륨 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨-생성하기)에 대해 자세히 알아보기
|
||||
* [퍼시스턴트볼륨클레임 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨클레임-생성하기)에 대해 자세히 알아보기
|
||||
* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기
|
||||
|
||||
### 참고
|
||||
|
|
|
|||
|
|
@ -410,6 +410,21 @@ parameters:
|
|||
|
||||
### vSphere
|
||||
|
||||
vSphere 스토리지 클래스에는 두 가지 유형의 프로비저닝 도구가 있다.
|
||||
|
||||
- [CSI 프로비저닝 도구](#csi-프로비저닝-도구): `csi.vsphere.vmware.com`
|
||||
- [vCP 프로비저닝 도구](#vcp-프로비저닝-도구): `kubernetes.io/vsphere-volume`
|
||||
|
||||
인-트리 프로비저닝 도구는 [사용 중단](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)되었다. CSI 프로비저닝 도구에 대한 자세한 내용은 [쿠버네티스 vSphere CSI 드라이버](https://vsphere-csi-driver.sigs.k8s.io/) 및 [vSphereVolume CSI 마이그레이션](/ko/docs/concepts/storage/volumes/#csi-마이그레이션)을 참고한다.
|
||||
|
||||
#### CSI 프로비저닝 도구 {#vsphere-provisioner-csi}
|
||||
|
||||
vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml)를 참조한다.
|
||||
|
||||
#### vCP 프로비저닝 도구
|
||||
|
||||
다음 예시에서는 VMware 클라우드 공급자(vCP) 스토리지클래스 프로비저닝 도구를 사용한다.
|
||||
|
||||
1. 사용자 지정 디스크 형식으로 스토리지클래스를 생성한다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -575,7 +590,7 @@ parameters:
|
|||
이 Quobyte 테넌트는 이미 Quobyte에 있어야 한다.
|
||||
기본값은 "DEFAULT".
|
||||
|
||||
### Azure 디스크크
|
||||
### Azure 디스크
|
||||
|
||||
#### Azure 비관리 디스크 스토리지 클래스 {#azure-unmanaged-disk-storage-class}
|
||||
|
||||
|
|
|
|||
|
|
@ -751,7 +751,7 @@ spec:
|
|||
### persistentVolumeClaim {#persistentvolumeclaim}
|
||||
|
||||
`persistentVolumeClaim` 볼륨은
|
||||
[퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes)을 파드에 마운트하는데 사용한다. 퍼시스턴트볼륨은
|
||||
[퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes)을 파드에 마운트하는데 사용한다. 퍼시스턴트볼륨클레임은
|
||||
사용자가 특정 클라우드 환경의 세부 내용을 몰라도 내구성이있는 스토리지 (GCE 퍼시스턴트디스크 또는
|
||||
iSCSI 볼륨와 같은)를 "클레임" 할 수 있는 방법이다.
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
|
|||
|
||||
{{< codenew file="application/job/cronjob.yaml" >}}
|
||||
|
||||
([크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)는
|
||||
([크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)는
|
||||
이 예시를 더 자세히 설명한다.)
|
||||
|
||||
## 크론잡의 한계 {#cron-job-limitations}
|
||||
|
|
@ -85,4 +85,4 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
|
|||
크론잡 `schedule` 필드의 포맷을 문서화 한다.
|
||||
|
||||
크론잡 생성과 작업에 대한 지침과 크론잡 매니페스트의
|
||||
예는 [크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다.
|
||||
예는 [크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다.
|
||||
|
|
|
|||
|
|
@ -331,7 +331,7 @@ spec:
|
|||
- 각 작업 항목에 대한 하나의 잡 오브젝트 vs 모든 작업 항목에 대한 단일 잡 오브젝트. 후자는
|
||||
작업 항목 수가 많은 경우 더 적합하다. 전자는 사용자와 시스템이 많은 수의 잡 오브젝트를
|
||||
관리해야 하는 약간의 오버헤드를 만든다.
|
||||
- 작업 항목과 동일한 개수의 파드 생성 vs 각 파드에서 다수의 작업 항목을 처리
|
||||
- 작업 항목과 동일한 개수의 파드 생성 vs 각 파드에서 다수의 작업 항목을 처리.
|
||||
전자는 일반적으로 기존 코드와 컨테이너를 거의 수정할 필요가 없다. 후자는
|
||||
이전 글 머리표(-)와 비슷한 이유로 많은 수의 작업 항목에 적합하다.
|
||||
- 여러 접근 방식이 작업 큐를 사용한다. 이를 위해서는 큐 서비스를 실행하고,
|
||||
|
|
@ -346,7 +346,7 @@ spec:
|
|||
| -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:|
|
||||
| [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ |
|
||||
| [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 때때로 | ✓ |
|
||||
| [가변 파드 수를 가진 큐](/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ |
|
||||
| [가변 파드 수를 가진 큐](/ko/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ |
|
||||
| 정적 작업이 할당된 단일 잡 | ✓ | | ✓ | |
|
||||
|
||||
`.spec.completions` 로 완료를 지정할 때, 잡 컨트롤러에 의해 생성된 각 파드는
|
||||
|
|
@ -362,7 +362,7 @@ spec:
|
|||
| -------------------------------------------------------------------- |:-------------------:|:--------------------:|
|
||||
| [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/) | 1 | 1이어야 함 |
|
||||
| [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | any |
|
||||
| [가변 파드 수를 가진 큐](/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | any |
|
||||
| [가변 파드 수를 가진 큐](/ko/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | any |
|
||||
| 정적 작업이 할당된 단일 잡 | W | any |
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
|
|||
{{< /note >}}
|
||||
|
||||
파드 오브젝트에 대한 매니페스트를 만들 때, 지정된 이름이 유효한
|
||||
[DNS 하위 도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인한다.
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인한다.
|
||||
|
||||
### 파드와 컨트롤러
|
||||
|
||||
|
|
|
|||
|
|
@ -30,13 +30,23 @@ node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB
|
|||
|
||||
그러면 클러스터는 논리적으로 다음과 같이 보이게 된다.
|
||||
|
||||
```
|
||||
+---------------+---------------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 |
|
||||
+-------+-------+-------+-------+
|
||||
```
|
||||
{{<mermaid>}}
|
||||
graph TB
|
||||
subgraph "zoneB"
|
||||
n3(Node3)
|
||||
n4(Node4)
|
||||
end
|
||||
subgraph "zoneA"
|
||||
n1(Node1)
|
||||
n2(Node2)
|
||||
end
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n1,n2,n3,n4 k8s;
|
||||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/kubernetes-api/labels-annotations-taints/)을 재사용할 수 있다.
|
||||
|
||||
|
|
@ -80,17 +90,25 @@ spec:
|
|||
|
||||
### 예시: 단수 토폴로지 분배 제약 조건
|
||||
|
||||
4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다(`P`는 파드를 나타낸다).
|
||||
4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다.
|
||||
|
||||
```
|
||||
+---------------+---------------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 |
|
||||
+-------+-------+-------+-------+
|
||||
| P | P | P | |
|
||||
+-------+-------+-------+-------+
|
||||
```
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneB"
|
||||
p3(Pod) --> n3(Node3)
|
||||
n4(Node4)
|
||||
end
|
||||
subgraph "zoneA"
|
||||
p1(Pod) --> n1(Node1)
|
||||
p2(Pod) --> n2(Node2)
|
||||
end
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n1,n2,n3,n4,p1,p2,p3 k8s;
|
||||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
신규 파드가 기존 파드와 함께 영역에 걸쳐서 균등하게 분배되도록 하려면, 스펙(spec)은 다음과 같이 주어질 수 있다.
|
||||
|
||||
|
|
@ -100,15 +118,46 @@ spec:
|
|||
|
||||
만약 스케줄러가 이 신규 파드를 "zoneA"에 배치하면 파드 분포는 [3, 1]이 되며, 따라서 실제 차이(skew)는 2 (3 - 1)가 되어 `maxSkew: 1` 를 위반하게 된다. 이 예시에서는 들어오는 파드는 오직 "zoneB"에만 배치할 수 있다.
|
||||
|
||||
```
|
||||
+---------------+---------------+ +---------------+---------------+
|
||||
| zoneA | zoneB | | zoneA | zoneB |
|
||||
+-------+-------+-------+-------+ +-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 | OR | node1 | node2 | node3 | node4 |
|
||||
+-------+-------+-------+-------+ +-------+-------+-------+-------+
|
||||
| P | P | P | P | | P | P | P P | |
|
||||
+-------+-------+-------+-------+ +-------+-------+-------+-------+
|
||||
```
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneB"
|
||||
p3(Pod) --> n3(Node3)
|
||||
p4(mypod) --> n4(Node4)
|
||||
end
|
||||
subgraph "zoneA"
|
||||
p1(Pod) --> n1(Node1)
|
||||
p2(Pod) --> n2(Node2)
|
||||
end
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n1,n2,n3,n4,p1,p2,p3 k8s;
|
||||
class p4 plain;
|
||||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
OR
|
||||
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneB"
|
||||
p3(Pod) --> n3(Node3)
|
||||
p4(mypod) --> n3
|
||||
n4(Node4)
|
||||
end
|
||||
subgraph "zoneA"
|
||||
p1(Pod) --> n1(Node1)
|
||||
p2(Pod) --> n2(Node2)
|
||||
end
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n1,n2,n3,n4,p1,p2,p3 k8s;
|
||||
class p4 plain;
|
||||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
사용자는 파드 스펙을 조정해서 다음과 같은 다양한 요구사항을 충족할 수 있다.
|
||||
|
||||
|
|
@ -118,17 +167,26 @@ spec:
|
|||
|
||||
### 예시: 다중 토폴로지 분배 제약 조건
|
||||
|
||||
4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다(`P`는 파드를 나타낸다).
|
||||
4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다.
|
||||
|
||||
```
|
||||
+---------------+---------------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 |
|
||||
+-------+-------+-------+-------+
|
||||
| P | P | P | |
|
||||
+-------+-------+-------+-------+
|
||||
```
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneB"
|
||||
p3(Pod) --> n3(Node3)
|
||||
n4(Node4)
|
||||
end
|
||||
subgraph "zoneA"
|
||||
p1(Pod) --> n1(Node1)
|
||||
p2(Pod) --> n2(Node2)
|
||||
end
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n1,n2,n3,n4,p1,p2,p3 k8s;
|
||||
class p4 plain;
|
||||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
사용자는 2개의 TopologySpreadConstraints를 사용해서 영역과 노드에 파드를 분배하는 것을 제어할 수 있다.
|
||||
|
||||
|
|
@ -138,15 +196,24 @@ spec:
|
|||
|
||||
다중 제약 조건은 충돌로 이어질 수 있다. 3개의 노드를 가지는 클러스터 하나가 2개의 영역에 걸쳐 있다고 가정한다.
|
||||
|
||||
```
|
||||
+---------------+-------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+
|
||||
| node1 | node2 | node3 |
|
||||
+-------+-------+-------+
|
||||
| P P | P | P P |
|
||||
+-------+-------+-------+
|
||||
```
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneB"
|
||||
p4(Pod) --> n3(Node3)
|
||||
p5(Pod) --> n3
|
||||
end
|
||||
subgraph "zoneA"
|
||||
p1(Pod) --> n1(Node1)
|
||||
p2(Pod) --> n1
|
||||
p3(Pod) --> n2(Node2)
|
||||
end
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s;
|
||||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
만약 사용자가 "two-constraints.yaml" 을 이 클러스터에 적용하면, "mypod"가 `Pending` 상태로 유지되는 것을 알게 된다. 이러한 이유는, 첫 번째 제약 조건을 충족하기 위해 "mypod"는 오직 "zoneB"에만 놓을 수 있다. 두 번째 제약 조건에서는 "mypod"는 오직 "node2"에만 놓을 수 있다. 그러면 "zoneB"와 "node2"의 공동 결과는 아무것도 반환되지 않는다.
|
||||
|
||||
|
|
@ -169,15 +236,37 @@ spec:
|
|||
|
||||
zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
|
||||
|
||||
```
|
||||
+---------------+---------------+-------+
|
||||
| zoneA | zoneB | zoneC |
|
||||
+-------+-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 | node5 |
|
||||
+-------+-------+-------+-------+-------+
|
||||
| P | P | P | | |
|
||||
+-------+-------+-------+-------+-------+
|
||||
```
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneB"
|
||||
p3(Pod) --> n3(Node3)
|
||||
n4(Node4)
|
||||
end
|
||||
subgraph "zoneA"
|
||||
p1(Pod) --> n1(Node1)
|
||||
p2(Pod) --> n2(Node2)
|
||||
end
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n1,n2,n3,n4,p1,p2,p3 k8s;
|
||||
class p4 plain;
|
||||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneC"
|
||||
n5(Node5)
|
||||
end
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n5 k8s;
|
||||
class zoneC cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
그리고 알다시피 "zoneC"는 제외해야 한다. 이 경우에, "mypod"가 "zoneC"가 아닌 "zoneB"에 배치되도록 yaml을 다음과 같이 구성할 수 있다. 마찬가지로 `spec.nodeSelector` 도 존중된다.
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ card:
|
|||
|
||||
기존 콘텐츠에 대한 개선을 제안하거나, 오류를 발견하면, 이슈를 연다.
|
||||
|
||||
1. 페이지 하단으로 이동하여 **이슈 생성하기** 버튼을 클릭한다. 그러면 헤더가
|
||||
1. 오른쪽 사이드바에서 **문서에 이슈 생성** 링크를 클릭한다. 그러면 헤더가
|
||||
미리 채워진 GitHub 이슈 페이지로 리디렉션된다.
|
||||
2. 개선을 위한 문제나 제안 사항을 설명한다. 가능한 한 많은 정보를 제공한다.
|
||||
3. **Submit new issue** 를 클릭한다.
|
||||
|
|
@ -61,5 +61,3 @@ card:
|
|||
- [행동 강령](/ko/community/code-of-conduct/)을 따른다. 동료 기여자를
|
||||
존중한다. 예를 들어, "문서가 끔찍하다"는 도움이
|
||||
되지 않거나 예의 바르지 않은 피드백이다.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ weight: 60
|
|||
|
||||
<!-- body -->
|
||||
쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다.
|
||||
인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)를
|
||||
인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)를
|
||||
참고한다.
|
||||
|
||||
쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다.
|
||||
|
|
@ -42,7 +42,7 @@ weight: 60
|
|||
* **extra** - 인증 계층에서 제공하는 문자열 값에 대한 임의의 문자열 키 맵.
|
||||
* **API** - 요청이 API 리소스에 대한 것인지 여부.
|
||||
* **Request path** - `/api` 또는 `/healthz`와 같이 다양한 리소스가 아닌 엔드포인트의 경로.
|
||||
* **API request verb** - `get`, `list`, `create`, `update`, `patch`, `watch`, `delete`, `deletecollection`과 같은 리소스 요청에 사용하는 API 동사. 리소스 API 엔드포인트의 요청 동사를 결정하려면 [요청 동사 결정](/docs/reference/access-authn-authz/authorization/#determine-the-request-verb)을 참고한다.
|
||||
* **API request verb** - `get`, `list`, `create`, `update`, `patch`, `watch`, `delete`, `deletecollection`과 같은 리소스 요청에 사용하는 API 동사. 리소스 API 엔드포인트의 요청 동사를 결정하려면 [요청 동사 결정](/ko/docs/reference/access-authn-authz/authorization/#요청-동사-결정)을 참고한다.
|
||||
* **HTTP request verb** - `get`, `post`, `put`, `delete`처럼 소문자 HTTP 메서드는 리소스가 아닌 요청에 사용한다.
|
||||
* **Resource** - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- `get`, `update`, `patch`, `delete` 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다.
|
||||
* **Subresource** - 접근 중인 하위 리소스(리소스 요청만 해당).
|
||||
|
|
@ -197,5 +197,5 @@ status:
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)에서 **인증**을 참조한다.
|
||||
* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)에서 **인증**을 참조한다.
|
||||
* 어드미션 제어에 대한 자세한 내용은 [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)를 참조한다.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ weight: 5
|
|||
<!-- body -->
|
||||
사용자는 `kubectl`, 클라이언트 라이브러리
|
||||
또는 REST 요청을 통해
|
||||
[API에 접근한다](/docs/tasks/access-application-cluster/access-cluster/).
|
||||
[API에 접근한다](/ko/docs/tasks/access-application-cluster/access-cluster/).
|
||||
사용자와 쿠버네티스 서비스 어카운트 모두 API에 접근할 수 있다.
|
||||
요청이 API에 도달하면,
|
||||
다음 다이어그램에 설명된 몇 가지 단계를 거친다.
|
||||
|
|
@ -100,7 +100,7 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
|
|||
|
||||
쿠버네티스는 ABAC 모드, RBAC 모드, 웹훅 모드와 같은 여러 개의 인가 모듈을 지원한다. 관리자가 클러스터를 생성할 때 API 서버에서 사용해야 하는 인가 모듈을 구성했다. 인가 모듈이 2개 이상 구성되면 쿠버네티스가 각 모듈을 확인하고, 어느 모듈이 요청을 승인하면 요청을 진행할 수 있다. 모든 모듈이 요청을 거부하면 요청이 거부된다(HTTP 상태 코드 403).
|
||||
|
||||
인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면 [인가 개요](/docs/reference/access-authz/authorization/)를 참조한다.
|
||||
인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면 [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)를 참조한다.
|
||||
|
||||
|
||||
## 어드미션 제어
|
||||
|
|
@ -159,4 +159,3 @@ GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 `kube-up.sh
|
|||
API 서버는 포트 443에서 서비스한다.
|
||||
GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다.
|
||||
이외에 클러스터 설정 방법은 다양하다.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,6 +7,6 @@ weight: 5
|
|||
card:
|
||||
name: reference
|
||||
weight: 10
|
||||
title: Glossary
|
||||
title: 용어집
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -16,4 +16,4 @@ short-description: >
|
|||
|
||||
<!--more-->
|
||||
|
||||
[파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)은 파드의 라이프사이클에 대한 고수준의 요약이다. 다섯 가지 파드 단계가 있다: Pending, Running, Succeeded, Failed, 그리고 Unknown. [파드 스테이터스](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core)의 `phase` 필드에 파드 상태에 대한 자세한 설명이 요약되어 있다.
|
||||
[파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)은 파드의 라이프사이클에 대한 고수준의 요약이다. 다섯 가지 파드 단계가 있다: Pending, Running, Succeeded, Failed, 그리고 Unknown. [파드 스테이터스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)의 `phase` 필드에 파드 상태에 대한 자세한 설명이 요약되어 있다.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,372 @@
|
|||
---
|
||||
title: 도커 사용자를 위한 kubectl
|
||||
content_type: concept
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
당신은 쿠버네티스 커맨드 라인 도구인 kubectl을 사용하여 API 서버와 상호 작용할 수 있다. 만약 도커 커맨드 라인 도구에 익숙하다면 kubectl을 사용하는 것은 간단하다. 다음 섹션에서는 도커의 하위 명령을 보여주고 kubectl과 같은 명령어를 설명한다.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## docker run
|
||||
|
||||
nginx 디플로이먼트(Deployment)를 실행하고 해당 디플로이먼트를 노출시키려면, [kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-)을 참고한다.
|
||||
docker:
|
||||
|
||||
```shell
|
||||
docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx
|
||||
```
|
||||
```
|
||||
55c103fa129692154a7652490236fee9be47d70a8dd562281ae7d2f9a339a6db
|
||||
```
|
||||
|
||||
```shell
|
||||
docker ps
|
||||
```
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
55c103fa1296 nginx "nginx -g 'daemon of…" 9 seconds ago Up 9 seconds 0.0.0.0:80->80/tcp nginx-app
|
||||
```
|
||||
|
||||
kubectl:
|
||||
|
||||
```shell
|
||||
# nginx 실행하는 파드를 시작한다
|
||||
kubectl create deployment --image=nginx nginx-app
|
||||
```
|
||||
|
||||
```shell
|
||||
# nginx-app 에 env를 추가한다
|
||||
kubectl set env deployment/nginx-app DOMAIN=cluster
|
||||
```
|
||||
```
|
||||
deployment.apps/nginx-app created
|
||||
```
|
||||
|
||||
```
|
||||
# nginx-app 에 env를 추가한다
|
||||
kubectl set env deployment/nginx-app DOMAIN=cluster
|
||||
```
|
||||
```
|
||||
deployment.apps/nginx-app env updated
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`kubectl` 커맨드는 생성되거나 변경된 리소스의 유형과 이름을 출력하므로, 이를 후속 커맨드에 사용할 수 있다. 디플로이먼트가 생성된 후에는 새로운 서비스를 노출할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
# 서비스를 통해 포트를 노출
|
||||
kubectl expose deployment nginx-app --port=80 --name=nginx-http
|
||||
```
|
||||
```
|
||||
service "nginx-http" exposed
|
||||
```
|
||||
|
||||
kubectl을 사용하면, N개의 파드가 nginx를 실행하도록 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 생성할 수 있다. 여기서 N은 스펙에 명시된 레플리카 수이며, 기본값은 1이다. 또한 파드의 레이블과 셀럭터를 사용하여 서비스를 생성할 수 있다. 자세한 내용은 [클러스터 내 애플리케이션에 접근하기 위해 서비스 사용하기](/ko/docs/tasks/access-application-cluster/service-access-application-cluster)를 참고한다.
|
||||
|
||||
기본적으로 이미지는 `docker run -d ...` 와 비슷하게 백그라운드로 실행된다. 포그라운드로 실행하려면 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run)을 이용하여 파드를 생성한다.
|
||||
```shell
|
||||
kubectl run [-i] [--tty] --attach <name> --image=<image>
|
||||
```
|
||||
|
||||
`docker run ...` 과 달리 `--attach` 를 지정하면 `표준 입력(stdin)`, `표준 출력(stdout)` 및 `표준 오류(stderr)`가 붙는다. 연결된(attached) 스트림을 제어할 수 없다(`docker -a ...`).
|
||||
해당 컨테이너에서 분리(detach)하려면 이스케이프 시퀀스(escape sequence) Ctrl+P를 입력한 다음 Ctrl+Q를 입력한다.
|
||||
|
||||
## docker ps
|
||||
|
||||
현재 실행 중인 목록을 보기 위해서는 [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get)을 참고한다.
|
||||
|
||||
docker:
|
||||
|
||||
```shell
|
||||
docker ps -a
|
||||
```
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
14636241935f ubuntu:16.04 "echo test" 5 seconds ago Exited (0) 5 seconds ago cocky_fermi
|
||||
55c103fa1296 nginx "nginx -g 'daemon of…" About a minute ago Up About a minute 0.0.0.0:80->80/tcp nginx-app
|
||||
```
|
||||
|
||||
kubectl:
|
||||
|
||||
```shell
|
||||
kubectl get po
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-app-8df569cb7-4gd89 1/1 Running 0 3m
|
||||
ubuntu 0/1 Completed 0 20s
|
||||
```
|
||||
|
||||
## docker attach
|
||||
|
||||
이미 실행 중인 컨테이너에 연결하려면 [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach)를 참고한다.
|
||||
|
||||
docker:
|
||||
|
||||
```shell
|
||||
docker ps
|
||||
```
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
55c103fa1296 nginx "nginx -g 'daemon of…" 5 minutes ago Up 5 minutes 0.0.0.0:80->80/tcp nginx-app
|
||||
```
|
||||
|
||||
```shell
|
||||
docker attach 55c103fa1296
|
||||
...
|
||||
```
|
||||
|
||||
kubectl:
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-app-5jyvm 1/1 Running 0 10m
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl attach -it nginx-app-5jyvm
|
||||
...
|
||||
```
|
||||
|
||||
컨테이너에서 분리하려면 이스케이프 시퀀스 Ctrl+P를 입력한 다음 Ctrl+Q를 입력한다.
|
||||
|
||||
## docker exec
|
||||
|
||||
컨테이너에서 커맨드를 실행하려면 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 참고한다.
|
||||
|
||||
docker:
|
||||
|
||||
```shell
|
||||
docker ps
|
||||
```
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
55c103fa1296 nginx "nginx -g 'daemon of…" 6 minutes ago Up 6 minutes 0.0.0.0:80->80/tcp nginx-app
|
||||
```
|
||||
```shell
|
||||
docker exec 55c103fa1296 cat /etc/hostname
|
||||
```
|
||||
```
|
||||
55c103fa1296
|
||||
```
|
||||
|
||||
kubectl:
|
||||
|
||||
```shell
|
||||
kubectl get po
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-app-5jyvm 1/1 Running 0 10m
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl exec nginx-app-5jyvm -- cat /etc/hostname
|
||||
```
|
||||
```
|
||||
nginx-app-5jyvm
|
||||
```
|
||||
|
||||
대화형 커맨드를 사용한다.
|
||||
|
||||
|
||||
docker:
|
||||
|
||||
```shell
|
||||
docker exec -ti 55c103fa1296 /bin/sh
|
||||
# exit
|
||||
```
|
||||
|
||||
kubectl:
|
||||
|
||||
```shell
|
||||
kubectl exec -ti nginx-app-5jyvm -- /bin/sh
|
||||
# exit
|
||||
```
|
||||
|
||||
자세한 내용은 [실행 중인 컨테이너의 셸 얻기](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고한다.
|
||||
|
||||
## docker logs
|
||||
|
||||
실행 중인 프로세스의 표준 입력(stdout)/표준 오류(stderr)를 수행하려면 [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs)를 참고한다.
|
||||
|
||||
|
||||
docker:
|
||||
|
||||
```shell
|
||||
docker logs -f a9e
|
||||
```
|
||||
```
|
||||
192.168.9.1 - - [14/Jul/2015:01:04:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
|
||||
192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
|
||||
```
|
||||
|
||||
kubectl:
|
||||
|
||||
```shell
|
||||
kubectl logs -f nginx-app-zibvs
|
||||
```
|
||||
```
|
||||
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
|
||||
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
|
||||
```
|
||||
|
||||
파드와 컨테이너에는 근소한 차이가 있다. 기본적으로 파드는 프로세스가 종료되어도 종료되지 않는다. 대신 파드가 프로세스를 다시 시작한다. 이는 도커의 실행 옵션인 `--restart=always`와 유사하지만, 한 가지 큰 차이점이 있다. 도커에서는 프로세스의 각 호출에 대한 출력이 연결되지만, 쿠버네티스의 경우 각 호출은 별개다. 쿠버네티스에서 이전 실행의 출력 내용을 보려면 다음을 수행한다.
|
||||
|
||||
```shell
|
||||
kubectl logs --previous nginx-app-zibvs
|
||||
```
|
||||
```
|
||||
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
|
||||
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
|
||||
```
|
||||
|
||||
자세한 정보는 [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 참고한다.
|
||||
|
||||
## docker stop 과 docker rm
|
||||
|
||||
실행 중인 프로세스를 중지하고 삭제하려면 [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete)을 참고한다.
|
||||
|
||||
docker:
|
||||
|
||||
```shell
|
||||
docker ps
|
||||
```
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
a9ec34d98787 nginx "nginx -g 'daemon of" 22 hours ago Up 22 hours 0.0.0.0:80->80/tcp, 443/tcp nginx-app
|
||||
```
|
||||
|
||||
```shell
|
||||
docker stop a9ec34d98787
|
||||
```
|
||||
```
|
||||
a9ec34d98787
|
||||
```
|
||||
|
||||
```shell
|
||||
docker rm a9ec34d98787
|
||||
```
|
||||
```
|
||||
a9ec34d98787
|
||||
```
|
||||
|
||||
kubectl:
|
||||
|
||||
```shell
|
||||
kubectl get deployment nginx-app
|
||||
```
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-app 1/1 1 1 2m
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get po -l run=nginx-app
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-app-2883164633-aklf7 1/1 Running 0 2m
|
||||
```
|
||||
```shell
|
||||
kubectl delete deployment nginx-app
|
||||
```
|
||||
```
|
||||
deployment "nginx-app" deleted
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get po -l run=nginx-app
|
||||
# 아무것도 반환하지 않는다
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
kubectl을 사용할 때는 파드를 직접 삭제하지 않는다. 먼저 파드를 소유한 디플로이먼트를 삭제해야 한다. 만약 파드를 직접 삭제하면 디플로이먼트가 파드를 재생성할 것이다.
|
||||
{{< /note >}}
|
||||
|
||||
## docker login
|
||||
|
||||
kubectl은 `docker login`와 직접적인 유사점은 없다. 프라이빗 레지스트리와 함께 쿠버네티스를 사용하려면 [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)을 참고한다.
|
||||
|
||||
## docker version
|
||||
|
||||
클라이언트와 서버의 버전을 가져오려면 [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version)을 참고한다.
|
||||
|
||||
docker:
|
||||
|
||||
```shell
|
||||
docker version
|
||||
```
|
||||
```
|
||||
Client version: 1.7.0
|
||||
Client API version: 1.19
|
||||
Go version (client): go1.4.2
|
||||
Git commit (client): 0baf609
|
||||
OS/Arch (client): linux/amd64
|
||||
Server version: 1.7.0
|
||||
Server API version: 1.19
|
||||
Go version (server): go1.4.2
|
||||
Git commit (server): 0baf609
|
||||
OS/Arch (server): linux/amd64
|
||||
```
|
||||
|
||||
kubectl:
|
||||
|
||||
```shell
|
||||
kubectl version
|
||||
```
|
||||
```
|
||||
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
|
||||
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
|
||||
```
|
||||
|
||||
## docker info
|
||||
|
||||
환경 및 설정에 대한 자세한 정보는 [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info)를 참고한다.
|
||||
|
||||
docker:
|
||||
|
||||
```shell
|
||||
docker info
|
||||
```
|
||||
```
|
||||
Containers: 40
|
||||
Images: 168
|
||||
Storage Driver: aufs
|
||||
Root Dir: /usr/local/google/docker/aufs
|
||||
Backing Filesystem: extfs
|
||||
Dirs: 248
|
||||
Dirperm1 Supported: false
|
||||
Execution Driver: native-0.2
|
||||
Logging Driver: json-file
|
||||
Kernel Version: 3.13.0-53-generic
|
||||
Operating System: Ubuntu 14.04.2 LTS
|
||||
CPUs: 12
|
||||
Total Memory: 31.32 GiB
|
||||
Name: k8s-is-fun.mtv.corp.google.com
|
||||
ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO
|
||||
WARNING: No swap limit support
|
||||
```
|
||||
|
||||
kubectl:
|
||||
|
||||
```shell
|
||||
kubectl cluster-info
|
||||
```
|
||||
```
|
||||
Kubernetes master is running at https://203.0.113.141
|
||||
KubeDNS is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
|
||||
kubernetes-dashboard is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
|
||||
Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
|
||||
Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
|
||||
InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
|
||||
```
|
||||
|
||||
|
|
@ -125,14 +125,15 @@ kubectl [command] [TYPE] [NAME] [flags]
|
|||
|
||||
다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다.
|
||||
|
||||
(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.13.3 부터 일치했다.)
|
||||
(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.19.1 에서의 출력을 기준으로 한다.)
|
||||
|
||||
| 리소스 이름 | 짧은 이름 | API 그룹 | 네임스페이스 | 리소스 종류 |
|
||||
| NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND |
|
||||
|---|---|---|---|---|
|
||||
| `bindings` | | | true | Binding|
|
||||
| `bindings` | | | true | Binding |
|
||||
| `componentstatuses` | `cs` | | false | ComponentStatus |
|
||||
| `configmaps` | `cm` | | true | ConfigMap |
|
||||
| `endpoints` | `ep` | | true | Endpoints |
|
||||
| `events` | `ev` | | true | Event |
|
||||
| `limitranges` | `limits` | | true | LimitRange |
|
||||
| `namespaces` | `ns` | | false | Namespace |
|
||||
| `nodes` | `no` | | false | Node |
|
||||
|
|
@ -140,14 +141,14 @@ kubectl [command] [TYPE] [NAME] [flags]
|
|||
| `persistentvolumes` | `pv` | | false | PersistentVolume |
|
||||
| `pods` | `po` | | true | Pod |
|
||||
| `podtemplates` | | | true | PodTemplate |
|
||||
| `replicationcontrollers` | `rc` | | true| ReplicationController |
|
||||
| `replicationcontrollers` | `rc` | | true | ReplicationController |
|
||||
| `resourcequotas` | `quota` | | true | ResourceQuota |
|
||||
| `secrets` | | | true | Secret |
|
||||
| `serviceaccounts` | `sa` | | true | ServiceAccount |
|
||||
| `services` | `svc` | | true | Service |
|
||||
| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
|
||||
| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
|
||||
| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
|
||||
| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
|
||||
| `apiservices` | | apiregistration.k8s.io | false | APIService |
|
||||
| `controllerrevisions` | | apps | true | ControllerRevision |
|
||||
| `daemonsets` | `ds` | apps | true | DaemonSet |
|
||||
|
|
@ -164,9 +165,15 @@ kubectl [command] [TYPE] [NAME] [flags]
|
|||
| `jobs` | | batch | true | Job |
|
||||
| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
|
||||
| `leases` | | coordination.k8s.io | true | Lease |
|
||||
| `endpointslices` | | discovery.k8s.io | true | EndpointSlice |
|
||||
| `events` | `ev` | events.k8s.io | true | Event |
|
||||
| `ingresses` | `ing` | extensions | true | Ingress |
|
||||
| `flowschemas` | | flowcontrol.apiserver.k8s.io | false | FlowSchema |
|
||||
| `prioritylevelconfigurations` | | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration |
|
||||
| `ingressclasses` | | networking.k8s.io | false | IngressClass |
|
||||
| `ingresses` | `ing` | networking.k8s.io | true | Ingress |
|
||||
| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
|
||||
| `runtimeclasses` | | node.k8s.io | false | RuntimeClass |
|
||||
| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
|
||||
| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
|
||||
| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
|
||||
|
|
@ -176,7 +183,7 @@ kubectl [command] [TYPE] [NAME] [flags]
|
|||
| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
|
||||
| `csidrivers` | | storage.k8s.io | false | CSIDriver |
|
||||
| `csinodes` | | storage.k8s.io | false | CSINode |
|
||||
| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
|
||||
| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
|
||||
| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
|
||||
|
||||
## 출력 옵션
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ weight: 10
|
|||
- `PodFitsResources`: 파드의 요구 사항을 충족할 만큼 노드에 사용할 수 있는
|
||||
리소스(예: CPU 및 메모리)가 있는지 확인한다.
|
||||
|
||||
- `PodMatchNodeSelector`: 파드의 노드 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가
|
||||
- `MatchNodeSelector`: 파드의 노드 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가
|
||||
노드의 {{< glossary_tooltip text="레이블" term_id="label" >}}과 일치하는지 확인한다.
|
||||
|
||||
- `NoVolumeZoneConflict`: 해당 스토리지에 대한 장애 영역 제한이 주어지면
|
||||
|
|
@ -115,4 +115,4 @@ weight: 10
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기
|
||||
* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
|
||||
* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
|
||||
|
|
|
|||
|
|
@ -9,62 +9,61 @@ card:
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 쿠버네티스 API에 대한 개요를 제공한다.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, 컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은
|
||||
|
||||
REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작,
|
||||
컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는
|
||||
REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은
|
||||
API 오브젝트로 취급되고,
|
||||
[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다.
|
||||
|
||||
대부분의 작업은 API에 의존하고 있는
|
||||
[kubectl](/ko/docs/reference/kubectl/overview/) 커맨드라인 인터페이스 또는
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과 같은 다른 커맨드라인 툴을 통해 수행할 수 있다.
|
||||
그러나, REST 호출 사용을 통해서 API에 직접 접근할 수도 있다.
|
||||
|
||||
쿠버네티스 API를 사용하는 애플리케이션을 작성하는 경우
|
||||
[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)중 하나의 사용을 고려한다.
|
||||
|
||||
## API 버전 규칙
|
||||
|
||||
필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
|
||||
쿠버네티스는 `/api/v1`이나 `/apis/rbac.authorization.k8s.io/v1alpha1`과 같이
|
||||
각각 다른 API 경로에서 복수의 API 버전을 지원한다.
|
||||
JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서
|
||||
동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
|
||||
|
||||
아래를 위해 버전은 리소스나 필드 수준보다는 API 수준에서 설정된다.
|
||||
|
||||
- API가 시스템 리소스와 동작에 대해 명확하고 일관성 있게 표현하는 것을 보장
|
||||
- 수명 종료(end-of-life) 또는 실험적인 API 접근 제어 활성화
|
||||
|
||||
JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
|
||||
|
||||
{{< note >}}
|
||||
API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다.
|
||||
[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
|
||||
{{< /note >}}
|
||||
[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는
|
||||
API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
|
||||
|
||||
API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. [API 변경 문서](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.
|
||||
API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
|
||||
[API 변경 문서](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서
|
||||
각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.
|
||||
|
||||
아래는 각 수준의 기준에 대한 요약이다.
|
||||
|
||||
- 알파(Alpha) 수준:
|
||||
- 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
|
||||
- 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다. 기본적으로 비활성화되어 있다.
|
||||
- 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다.
|
||||
기본적으로 비활성화되어 있다.
|
||||
- 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
|
||||
- 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
|
||||
- 버그의 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
|
||||
- 버그의 위험이 높고 장기간 지원되지 않으므로
|
||||
단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
|
||||
|
||||
- 베타(Beta) 수준:
|
||||
- 버전 이름에 `beta`가 포함된다. (예: `v2beta3`).
|
||||
- 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. 기본적으로 활성화되어 있다.
|
||||
- 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다.
|
||||
기본적으로 활성화되어 있다.
|
||||
- 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
|
||||
- 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 이관할 수 있는 가이드가 제공된다. 이때 API 오브젝트의 삭제, 편집 또는 재생성이
|
||||
필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
|
||||
- 이후 여러 버전에서 잠재적으로 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면, 이런 제약에서 안심이 될 수도 있겠다.
|
||||
|
||||
{{< note >}}
|
||||
베타 기능을 사용해보고 피드백을 제공하자. 일단 베타가 끝나면, 실질적으로 더 많은 변경이 어렵다.
|
||||
{{< /note >}}
|
||||
- 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서
|
||||
호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로
|
||||
이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이
|
||||
필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다.
|
||||
이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
|
||||
- 이 소프트웨어는 프로덕션 용도로 권장되지 않는다. 이후 여러 버전에서
|
||||
호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서
|
||||
독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다.
|
||||
|
||||
{{< note >}}
|
||||
베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는
|
||||
실질적으로 더 많은 변경이 어렵다.
|
||||
{{< /note >}}
|
||||
|
||||
- 안정화(stable) 수준:
|
||||
- 버전 이름이 `vX`이고 `X` 는 정수다.
|
||||
|
|
@ -72,32 +71,43 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
|
|||
|
||||
## API 그룹
|
||||
|
||||
[*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은 쿠버네티스 API를 더 쉽게 확장하게 해준다. API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다.
|
||||
[API 그룹](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은
|
||||
쿠버네티스 API를 더 쉽게 확장하게 해준다.
|
||||
API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에
|
||||
명시된다.
|
||||
|
||||
현재 다음과 같은 다양한 API 그룹이 사용되고 있다:
|
||||
현재 다음과 같은 다양한 API 그룹이 사용되고 있다.
|
||||
|
||||
* *핵심* (또는 *레거시* 라고 불리는) 그룹은 `apiVersion: v1`와 같이 `apiVersion` 필드에 명시되지 않고 REST 경로 `/api/v1`에 있다.
|
||||
* 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다
|
||||
(예를 들어 `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [쿠버네티스 API 참조 문서](/ko/docs/reference/)에서 확인할 수 있다.
|
||||
* *핵심* (또는 *레거시* 라고 불리는) 그룹은 REST 경로 `/api/v1`에 있다.
|
||||
핵심 그룹은 `apiVersion` 필드의 일부로 명시되지 않는다. 예를
|
||||
들어, `apiVersion: v1` 와 같다.
|
||||
* 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며
|
||||
`apiVersion: $GROUP_NAME/$VERSION`을 사용한다(예를 들어, `apiVersion: batch/v1`).
|
||||
지원되는 API 그룹 전체의 목록은
|
||||
[쿠버네티스 API 참조 문서](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에서 확인할 수 있다.
|
||||
|
||||
[사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다.
|
||||
## API 그룹 활성화 또는 비활성화 {#enabling-or-disabling}
|
||||
|
||||
- 기본적인 CRUD 요구에는
|
||||
[커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
|
||||
- 쿠버네티스 API의 의미론적 전체 집합으로 사용자만의 Apiserver를 구현하려는 경우에는 [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
|
||||
특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서
|
||||
`--runtime-config` 를 설정하여 활성화 또는 비활성화할 수 있다.
|
||||
`--runtime-config` 플래그는 API 서버의 런타임 구성을 설명하는
|
||||
쉼표로 구분된 `<key>=<value>` 쌍을 허용한다. 예를 들면, 다음과 같다.
|
||||
|
||||
|
||||
## API 그룹 활성화 또는 비활성화 하기
|
||||
|
||||
특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나
|
||||
비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어:
|
||||
|
||||
- batch/v1을 비활성화하려면 `--runtime-config=batch/v1=false`로 설정
|
||||
- batch/v2alpha1을 활성화하려면 `--runtime-config=batch/v2alpha1`로 설정
|
||||
|
||||
이 플래그는 apiserver의 런타임 구성을 설명하는 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
|
||||
- `batch/v1` 을 비활성화하려면, `--runtime-config=batch/v1=false` 로 설정
|
||||
- `batch/v2alpha1` 을 활성화하려면, `--runtime-config=batch/v2alpha1` 으로 설정
|
||||
|
||||
{{< note >}}
|
||||
그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여
|
||||
`--runtime-config` 변경을 반영해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 지속성
|
||||
|
||||
쿠버네티스는 {{< glossary_tooltip term_id="etcd" >}}에 기록하여 API 리소스 측면에서
|
||||
직렬화된 상태를 저장한다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)에 대해 자세히 알아보기
|
||||
- [애그리게이터(aggregator)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)에
|
||||
대한 디자인 문서 읽기
|
||||
|
|
|
|||
|
|
@ -10,12 +10,6 @@ weight: 30
|
|||
테스트는 노드가 쿠버네티스를 위한 최소 요구조건을 만족하는지를 검증한다. 그리고 테스트를 통과한 노드는 쿠버네티스 클러스터에 참
|
||||
여할 자격이 주어진다.
|
||||
|
||||
## 제한 사항
|
||||
|
||||
쿠버네티스 1.5에서는 노드 적합성 테스트가 아래의 제약이 있다.
|
||||
|
||||
* 노드 적합성 테스트는 컨테이너 런타임으로 Docker만 지원한다.
|
||||
|
||||
## 노드 필수 구성 요소
|
||||
|
||||
노드 적합성 테스트를 실행하기 위해서는, 해당 노드는 표준 쿠버네티스 노드로서 동일한 전제조건을 만족해야 한다.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,119 @@
|
|||
---
|
||||
title: Kubespray로 쿠버네티스 설치하기
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Packet(베어메탈), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.
|
||||
|
||||
Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.
|
||||
|
||||
* 고가용성을 지닌 클러스터
|
||||
* 구성할 수 있는 속성들
|
||||
* 대부분의 인기있는 리눅스 배포판들에 대한 지원
|
||||
* Ubuntu 16.04, 18.04, 20.04
|
||||
* CentOS/RHEL/Oracle Linux 7, 8
|
||||
* Debian Buster, Jessie, Stretch, Wheezy
|
||||
* Fedora 31, 32
|
||||
* Fedora CoreOS
|
||||
* openSUSE Leap 15
|
||||
* Flatcar Container Linux by Kinvolk
|
||||
* 지속적인 통합 (CI) 테스트
|
||||
|
||||
클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, kubespray를 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), [kops](/docs/setup/production-environment/tools/kops/)와 [비교한 글](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)을 읽어보자.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 클러스터 생성하기
|
||||
|
||||
|
||||
### (1/5) 아래의 요건 충족하기
|
||||
|
||||
언더레이(underlay) [요건](https://github.com/kubernetes-sigs/kubespray#requirements)을 만족하는 프로비전 한다.
|
||||
|
||||
* **Ansible의 명령어를 실행하기 위해 Ansible v 2.9와 Python netaddr 라이브러리가 머신에 설치되어 있어야 한다**
|
||||
* **Ansible 플레이북을 실행하기 위해 2.11 (혹은 그 이상) 버전의 Jinja가 필요하다**
|
||||
* 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
|
||||
* 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다
|
||||
* **SSH 키**가 인벤토리의 모든 서버들에 복사되어야 한다
|
||||
* **방화벽은 관리되지 않는다**. 사용자가 예전 방식대로 고유한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다
|
||||
* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 한다. 그 뒤 `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다
|
||||
|
||||
Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다:
|
||||
|
||||
* 아래 클라우드 제공 업체를 위한 [Terraform](https://www.terraform.io/) 스크립트:
|
||||
* [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
|
||||
* [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
|
||||
* [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
|
||||
|
||||
### (2/5) 인벤토리 파일 구성하기
|
||||
|
||||
서버들을 프로비저닝 한 후, [Ansible의 인벤토리 파일](https://docs.ansible.com/ansible/intro_inventory.html)을 만들어야 한다. 수동으로 만들 수도 있고, 동적인 인벤토리 스크립트를 통해 만들 수도 있다. 더 많이 알고싶다면 " [나만의 인벤토리 만들기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)" 글을 확인하자.
|
||||
|
||||
### (3/5) 클러스터 디플로이먼트 계획하기
|
||||
|
||||
Kubespray에서는 디플로이먼트의 많은 속성들을 사용자가 정의(customize)할 수 있다:
|
||||
|
||||
* 디플로이먼트 모드의 선택: kubeadm 또는 그 외
|
||||
* CNI(네트워킹) 플러그인
|
||||
* DNS 설정
|
||||
* 컨트롤 플레인 선택: 네이티브/바이너리 또는 컨테이너화 된 것
|
||||
* 컴포넌트 버전
|
||||
* Calico 라우터 리플렉터
|
||||
* 컴포넌트 런타임 옵션
|
||||
* {{< glossary_tooltip term_id="docker" >}}
|
||||
* {{< glossary_tooltip term_id="containerd" >}}
|
||||
* {{< glossary_tooltip term_id="cri-o" >}}
|
||||
* 인증서 생성 방법
|
||||
|
||||
Kubespray의 [변수 파일들](https://docs.ansible.com/ansible/playbooks_variables.html)을 사용자가 정의할 수 있다. 만약 Kubespray를 막 시작한 경우, kubespray의 기본 설정값을 이용해 클러스터를 배포하고 Kubernetes를 탐색하는 것이 좋다.
|
||||
|
||||
### (4/5) 클러스터 배포하기
|
||||
|
||||
다음으로, 클러스터를 배포한다.
|
||||
|
||||
[Ansible-플레이북](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment)을 이용한 클러스터 디플로이먼트
|
||||
|
||||
```shell
|
||||
ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
|
||||
--private-key=~/.ssh/private_key
|
||||
```
|
||||
|
||||
규모가 큰 디플로이먼트는 (100개 이상의 노드) 최적의 결과를 얻기 위해 [특정한 조정](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md)을 필요로 할 수도 있다.
|
||||
|
||||
### (5/5) 디플로이먼트 검증하기
|
||||
|
||||
Kubespray는 Netchecker를 사용하여 파드 사이의 연결성과 DNS 해석을 검증할 방법을 제공한다. Netchecker는 netchecker-agents 파드들이 DNS 요청을 해석하고 기본(default) 네임스페이스 내부에서 서로에게 ping을 보낼 수 있도록 보장한다. 그 파드들은 나머지 워크로드의 유사한 동작을 모방하고 클러스터의 상태 표시기 역할을 한다.
|
||||
|
||||
## 클러스터 동작
|
||||
|
||||
Kubespray는 클러스터를 관리하기 위한 추가적인 플레이북, _scale_ 과 _upgrade_ 를 제공한다.
|
||||
|
||||
### 클러스터 스케일링하기
|
||||
|
||||
scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "[노드 추가하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)" 문서를 확인하자. remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "[노드 제거하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)" 문서를 확인하자.
|
||||
|
||||
### 클러스터 업그레이드 하기
|
||||
|
||||
upgrade-cluster 플레이북을 실행해 클러스터를 업그레이드 할 수 있다. 더 자세히 알고 싶다면 "[업그레이드](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)" 문서를 확인하자.
|
||||
|
||||
## 클린업
|
||||
|
||||
[reset 플레이북](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml)을 이용하여 노드들을 리셋하고 Kubespray로 설치된 모든 구성요소를 삭제할 수 있다.
|
||||
|
||||
{{< caution >}}
|
||||
reset 플레이북을 실행할 때, 실수로 프로덕션 클러스터를 타겟으로 삼지 않도록 해야 한다!
|
||||
{{< /caution >}}
|
||||
|
||||
## 피드백
|
||||
|
||||
* Slack 채널: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) ([이 곳](https://slack.k8s.io/)에서 초대를 받을 수 있다)
|
||||
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Kubespray의 [로드맵](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)에서 계획중인 작업을 확인해보자.
|
||||
|
||||
|
|
@ -14,7 +14,7 @@ weight: 65
|
|||
|
||||
## 쿠버네티스의 윈도우 컨테이너
|
||||
|
||||
쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함하기만 하면 된다. 쿠버네티스의 [파드](/ko/docs/concepts/workloads/pods/pod-overview/)에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것만큼 간단하고 쉽다.
|
||||
쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함하기만 하면 된다. 쿠버네티스의 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것만큼 간단하고 쉽다.
|
||||
|
||||
윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 서버 2019는 윈도우에서 [쿠버네티스 노드](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)를 활성화하는 유일한 윈도우 운영 체제이다(kubelet, [컨테이너 런타임](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/containerd) 및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 [Microsoft 문서](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)를 참고한다.
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨
|
|||
|
||||
윈도우에서 주요 쿠버네티스 요소는 리눅스와 동일한 방식으로 작동한다. 이 섹션에서는, 주요 워크로드 인에이블러(enabler) 일부와 이들이 윈도우에 매핑되는 방법에 대해 설명한다.
|
||||
|
||||
* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [파드](/ko/docs/concepts/workloads/pods/)
|
||||
|
||||
파드는 쿠버네티스의 기본 빌딩 블록이다 - 쿠버네티스 오브젝트 모델에서 생성하고 배포하는 가장 작고 간단한 단위. 동일한 파드에 윈도우 및 리눅스 컨테이너를 배포할 수 없다. 파드의 모든 컨테이너는 단일 노드로 스케줄되며 각 노드는 특정 플랫폼 및 아키텍처를 나타낸다. 다음과 같은 파드 기능, 속성 및 이벤트가 윈도우 컨테이너에서 지원된다.
|
||||
|
||||
|
|
@ -81,7 +81,7 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨
|
|||
* 레플리카셋(ReplicaSet)
|
||||
* 레플리케이션컨트롤러(ReplicationController)
|
||||
* 디플로이먼트(Deployment)
|
||||
* 스테이트풀셋(StatefulSet)
|
||||
* 스테이트풀셋(StatefulSet)
|
||||
* 데몬셋(DaemonSet)
|
||||
* 잡(Job)
|
||||
* 크론잡(CronJob)
|
||||
|
|
@ -198,7 +198,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
|
|||
윈도우에서는 다음 IPAM 옵션이 지원된다.
|
||||
|
||||
* [호스트-로컬](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local)
|
||||
* HNS IPAM(Inbox 플랫폼 IPAM, 이것은 IPAM이 설정되지 않은 경우 폴백(fallback)이다)
|
||||
* HNS IPAM(Inbox 플랫폼 IPAM, 이것은 IPAM이 설정되지 않은 경우 폴백(fallback)이다)
|
||||
* [Azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md)(azure-cni 전용)
|
||||
|
||||
##### 로드 밸런싱과 서비스
|
||||
|
|
@ -255,9 +255,9 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
|
|||
|
||||
윈도우에는 리눅스처럼 out-of-memory 프로세스 킬러가 없다. 윈도우는 항상 모든 사용자 모드 메모리 할당을 가상으로 처리하며 페이지 파일은 필수이다. 결과적으로 윈도우는 리눅스와 같은 방식으로 메모리 부족 상태에 도달하지 않고, 메모리 부족(OOM)으로 인한 종료 대신 페이지를 디스크로 처리한다. 메모리가 과도하게 프로비저닝되고 모든 실제 메모리가 고갈되면, 페이징으로 인해 성능이 저하될 수 있다.
|
||||
|
||||
2단계 프로세스를 통해 적절한 범위 내에서 메모리 사용량을 유지할 수 있다. 먼저, kubelet 파라미터 `--kubelet-reserve` 그리고/또는 `--system-reserve`를 사용하여 노드(컨테이너 외부)의 메모리 사용량을 고려한다. 이렇게 하면 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)이 줄어든다. 워크로드를 배포할 때 컨테이너에 리소스 제한을 사용(limits만 설정하거나 limits이 requests과 같아야 함)한다. 또한 NodeAllocatable에서 빼고 노드가 가득차면 스케줄러가 더 많은 파드를 추가하지 못하도록 한다.
|
||||
2단계 프로세스를 통해 적절한 범위 내에서 메모리 사용량을 유지할 수 있다. 먼저, kubelet 파라미터 `--kubelet-reserve` 그리고/또는 `--system-reserve`를 사용하여 노드(컨테이너 외부)의 메모리 사용량을 고려한다. 이렇게 하면 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)이 줄어든다. 워크로드를 배포할 때 컨테이너에 리소스 제한을 사용(limits만 설정하거나 limits이 requests과 같아야 함)한다. 또한 NodeAllocatable에서 빼고 노드가 가득차면 스케줄러가 더 많은 파드를 추가하지 못하도록 한다.
|
||||
|
||||
오버 프로비저닝을 방지하는 모범 사례는 윈도우, 도커 및 쿠버네티스 프로세스를 고려하여 최소 2GB의 시스템 예약 메모리로 kubelet을 구성하는 것이다.
|
||||
오버 프로비저닝을 방지하는 모범 사례는 윈도우, 도커 및 쿠버네티스 프로세스를 고려하여 최소 2GB의 시스템 예약 메모리로 kubelet을 구성하는 것이다.
|
||||
|
||||
플래그의 동작은 아래에 설명된대로 다르게 동작한다.
|
||||
|
||||
|
|
@ -581,7 +581,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
|
|||
1. DNS 확인(resolution)이 제대로 작동하지 않는다.
|
||||
|
||||
이 [섹션](#dns-limitations)에서 윈도우에 대한 DNS 제한을 확인한다.
|
||||
|
||||
|
||||
1. `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다.
|
||||
|
||||
이는 쿠버네티스 1.15 및 pause 인프라 컨테이너 `mcr.microsoft.com/k8s/core/pause:1.2.0`에서 구현되었다. 해당 버전 또는 최신 버전을 사용해야 한다.
|
||||
|
|
@ -666,15 +666,13 @@ spec:
|
|||
|
||||
### kubeadm 및 클러스터 API를 사용한 배포
|
||||
|
||||
Kubeadm은 사용자가 쿠버네티스 클러스터를 배포하기 위한 사실상의 표준이
|
||||
되고 있다. kubeadm의 윈도우 노드 지원은 현재 작업 중이지만
|
||||
[여기](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)에서 가이드를 사용할 수 있다.
|
||||
또한 윈도우 노드가 적절하게 프로비저닝되도록 클러스터 API에
|
||||
Kubeadm은 사용자가 쿠버네티스 클러스터를 배포하기 위한 사실상의 표준이
|
||||
되고 있다. kubeadm의 윈도우 노드 지원은 현재 작업 중이지만
|
||||
[여기](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)에서 가이드를 사용할 수 있다.
|
||||
또한 윈도우 노드가 적절하게 프로비저닝되도록 클러스터 API에
|
||||
투자하고 있다.
|
||||
|
||||
### 몇 가지 기타 주요 기능
|
||||
* 그룹 관리 서비스 어카운트(Service Accounts)에 대한 베타 지원
|
||||
* 더 많은 CNI
|
||||
* 더 많은 스토리지 플러그인
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -149,8 +149,8 @@ root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다.
|
|||
|
||||
localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을
|
||||
요구하지 않지만 이는 표준이 아니다.
|
||||
[Configuring Access to the API](/docs/reference/access-authn-authz/controlling-access/)
|
||||
는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다.
|
||||
[API에 대한 접근 구성](/ko/docs/reference/access-authn-authz/controlling-access/)은
|
||||
클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다.
|
||||
이 방식들은 미래의 고가용성 지원과 충돌될 수 있다.
|
||||
|
||||
## API에 프로그래밍 방식으로 접근
|
||||
|
|
@ -218,7 +218,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
|
|||
이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은
|
||||
쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서
|
||||
[노드들](/ko/docs/concepts/architecture/nodes/),
|
||||
[파드들](/ko/docs/concepts/workloads/pods/pod/),
|
||||
[파드들](/ko/docs/concepts/workloads/pods/),
|
||||
[서비스들](/ko/docs/concepts/services-networking/service/)은
|
||||
모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
|
||||
클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을
|
||||
|
|
@ -375,4 +375,3 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy
|
|||
|
||||
일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는
|
||||
나머지 타입을 적절하게 구성해줘야 한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ card:
|
|||
|
||||
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면,
|
||||
`kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과
|
||||
[마이너 버전 하나 차이 이내](/ko/docs/setup/release/version-skew-policy/#kubectl)여야
|
||||
[마이너 버전 하나 차이 이내](/docs/setup/release/version-skew-policy/#kubectl)여야
|
||||
한다.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ weight: 10
|
|||
card:
|
||||
name: tasks
|
||||
weight: 30
|
||||
title: Use the Web UI Dashboard
|
||||
title: 웹 UI 대시보드 사용
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -52,7 +52,7 @@ kubectl 커맨드라인 도구를 이용해 다음 커맨드를 실행함으로
|
|||
kubectl proxy
|
||||
```
|
||||
|
||||
kubectl은 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ 에 대시보드를 사용하는 것을 가능하게 해줄 것이다.
|
||||
kubectl은 [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/)에 대시보드를 사용하는 것을 가능하게 해줄 것이다.
|
||||
|
||||
UI는 커맨드가 실행된 머신에서 _오직_ 접근 가능하다. 상세 내용은 `kubectl proxy --help` 옵션을 확인한다.
|
||||
|
||||
|
|
@ -170,7 +170,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
|
|||
커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
|
||||
|
||||
- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이
|
||||
[특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/pod/#파드-컨테이너의-특권-privileged-모드)의
|
||||
[특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/#컨테이너에-대한-특권-모드)의
|
||||
프로세스들과 동등한지 아닌지 정의한다.
|
||||
특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -148,7 +148,7 @@ http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한
|
|||
|
||||
일부 클러스터에서, API 서버는 인증이 필요하지 않다.
|
||||
로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은
|
||||
없다. [API에 대한 접근 구성](/docs/reference/access-authn-authz/controlling-access/)은
|
||||
없다. [API에 대한 접근 구성](/ko/docs/reference/access-authn-authz/controlling-access/)은
|
||||
클러스터 관리자가 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후
|
||||
고 가용성 지원과 충돌할 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ content_type: task
|
|||
## 클러스터에서 실행되는 서비스에 접근
|
||||
|
||||
쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/),
|
||||
[파드](/ko/docs/concepts/workloads/pods/pod/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
|
||||
[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
|
||||
고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수
|
||||
없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서
|
||||
도달할 수 없다.
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ L3/L4(예, IP 주소 + 포트) 모두의 보안 정책 뿐만 아니라 L7(예,
|
|||
## 실리움을 실 서비스 용도로 배포하기
|
||||
|
||||
실리움을 실 서비스 용도의 배포에 관련한 자세한 방법은
|
||||
[실리움 쿠버네티스 설치 안내](https://docs.cilium.io/en/stable/kubernetes/intro/)를 살펴본다.
|
||||
[실리움 쿠버네티스 설치 안내](https://docs.cilium.io/en/stable/concepts/kubernetes/intro/)를 살펴본다.
|
||||
이 문서는 자세한 요구사항, 방법과
|
||||
실제 데몬셋 예시를 포함한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,12 +17,12 @@ weight: 50
|
|||
|
||||
## Weave Net 애드온을 설치한다
|
||||
|
||||
[애드온을 통한 쿠버네티스 통합하기](https://www.weave.works/docs/net/latest/kube-addon/) 가이드를 따른다.
|
||||
[애드온을 통한 쿠버네티스 통합하기](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) 가이드를 따른다.
|
||||
|
||||
쿠버네티스의 위브넷 애드온은 쿠버네티스의 모든 네임스페이스의
|
||||
네크워크 정책 어노테이션을 자동으로 모니터링하며,
|
||||
정책에 따라 트래픽을 허용하고 차단하는 `iptables` 규칙을 구성하는
|
||||
[네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kube-addon/#npc)와 함께 제공된다.
|
||||
[네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#npc)와 함께 제공된다.
|
||||
|
||||
## 설치 시험
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ title: 리소스 모니터링 도구
|
|||
|
||||
애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면,
|
||||
애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다.
|
||||
컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod),
|
||||
컨테이너, [파드](/ko/docs/concepts/workloads/pods/),
|
||||
[서비스](/ko/docs/concepts/services-networking/service),
|
||||
그리고 전체 클러스터의 특성을 검사하여
|
||||
쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서
|
||||
|
|
|
|||
|
|
@ -0,0 +1,328 @@
|
|||
---
|
||||
title: 작업 대기열을 사용한 거친 병렬 처리
|
||||
min-kubernetes-server-version: v1.8
|
||||
content_type: task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 예제에서는, 여러 병렬 워커 프로세스를 활용해 쿠버네티스 잡(Job)을
|
||||
실행한다.
|
||||
|
||||
이 예제에서는, 각 파드가 생성될 때 작업 대기열에서 하나의 작업 단위를
|
||||
선택하여, 완료하고, 대기열에서 삭제하고, 종료한다.
|
||||
|
||||
이 예제에서의 단계에 대한 개요는 다음과 같다.
|
||||
|
||||
1. **메시지 대기열 서비스를 시작한다.** 이 예에서는, RabbitMQ를 사용하지만, 다른 메시지 대기열을 이용해도
|
||||
된다. 실제로 사용할 때는, 한 번 메시지 대기열 서비스를 구축하고서 이를 여러 잡을 위해 재사용하기도 한다.
|
||||
1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다.
|
||||
이 예제에서, 메시지는 긴 계산을 수행할 정수일 뿐이다.
|
||||
1. **대기열에서 작업을 수행하는 잡을 시작한다.** 잡은 여러 파드를 시작한다. 각 파드는
|
||||
메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
기본적이고, 병렬 작업이 아닌,
|
||||
[잡](/ko/docs/concepts/workloads/controllers/job/)의 사용법에 대해 잘 알고 있어야 한다.
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 메시지 대기열 서비스 시작
|
||||
|
||||
이 문서의 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 타입의 메시지 서비스에 적용하는데 문제가 없을 것이다.
|
||||
|
||||
실제로 사용할 때는, 클러스터에 메시지 대기열 서비스를 한 번
|
||||
구축하고서, 여러 많은 잡이나 오래 동작하는 서비스에 재사용할 수 있다.
|
||||
|
||||
다음과 같이 RabbitMQ를 시작한다.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.3/examples/celery-rabbitmq/rabbitmq-service.yaml
|
||||
```
|
||||
```
|
||||
service "rabbitmq-service" created
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.3/examples/celery-rabbitmq/rabbitmq-controller.yaml
|
||||
```
|
||||
```
|
||||
replicationcontroller "rabbitmq-controller" created
|
||||
```
|
||||
|
||||
이 문서에서는 [celery-rabbitmq 예제](https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/celery-rabbitmq)에 나오는 정도로만 rabbitmq를 사용한다.
|
||||
|
||||
## 메시지 대기열 서비스 테스트하기
|
||||
|
||||
이제, 메시지 대기열을 이용해 실험할 수 있다. 임시
|
||||
대화형 파드를 만들어 그 위에 도구들을 설치하고,
|
||||
대기열을 실험해본다.
|
||||
|
||||
먼저 임시 대화형 파드를 만든다.
|
||||
|
||||
```shell
|
||||
# 임시 대화형 컨테이너를 만든다.
|
||||
kubectl run -i --tty temp --image ubuntu:18.04
|
||||
```
|
||||
```
|
||||
Waiting for pod default/temp-loe07 to be running, status is Pending, pod ready: false
|
||||
... [ previous line repeats several times .. hit return when it stops ] ...
|
||||
```
|
||||
|
||||
참고로 파드 이름과 명령 프롬프트는 위와 다를 수 있다.
|
||||
|
||||
다음으로 `amqp-tools`를 설치하여 메시지 대기열을 활용할 수 있게 한다.
|
||||
|
||||
```shell
|
||||
# 도구들을 설치한다.
|
||||
root@temp-loe07:/# apt-get update
|
||||
.... [ lots of output ] ....
|
||||
root@temp-loe07:/# apt-get install -y curl ca-certificates amqp-tools python dnsutils
|
||||
.... [ lots of output ] ....
|
||||
```
|
||||
|
||||
후에, 이 패키지들을 포함하는 도커 이미지를 만든다.
|
||||
|
||||
다음으로, rabbitmq 서비스를 발견할 수 있는지 확인한다.
|
||||
|
||||
```
|
||||
# rabbitmq-service가 쿠버네티스로부터 주어진 DNS 이름을 갖는다.
|
||||
|
||||
root@temp-loe07:/# nslookup rabbitmq-service
|
||||
Server: 10.0.0.10
|
||||
Address: 10.0.0.10#53
|
||||
|
||||
Name: rabbitmq-service.default.svc.cluster.local
|
||||
Address: 10.0.147.152
|
||||
|
||||
# 주소는 다를 수 있다.
|
||||
```
|
||||
|
||||
만약 Kube-DNS가 적절히 구축되지 않았다면, 전 단계 작업이 작동하지 않을 수 있다.
|
||||
환경 변수를 통해서도 서비스 IP를 찾을 수 있다.
|
||||
|
||||
```
|
||||
# env | grep RABBIT | grep HOST
|
||||
RABBITMQ_SERVICE_SERVICE_HOST=10.0.147.152
|
||||
# 주소는 다를 수 있다.
|
||||
```
|
||||
|
||||
다음으로 대기열을 생성하고, 메시지를 발행하고 사용할 수 있는지 확인한다.
|
||||
|
||||
```shell
|
||||
# 다음 줄에서, rabbitmq-service는 rabbitmq-service에 접근할 수 있는
|
||||
# 호스트네임이다. 5672는 rabbitmq의 표준 포트이다.
|
||||
|
||||
root@temp-loe07:/# export BROKER_URL=amqp://guest:guest@rabbitmq-service:5672
|
||||
# 만약 전 단계에서 "rabbitmq-service"가 주소로 변환되지 않는다면,
|
||||
# 이 커맨드를 대신 사용하면 된다.
|
||||
# root@temp-loe07:/# BROKER_URL=amqp://guest:guest@$RABBITMQ_SERVICE_SERVICE_HOST:5672
|
||||
|
||||
# 이제 대기열을 생성한다.
|
||||
|
||||
root@temp-loe07:/# /usr/bin/amqp-declare-queue --url=$BROKER_URL -q foo -d
|
||||
foo
|
||||
|
||||
# 대기열에 메시지를 하나 발행한다.
|
||||
|
||||
root@temp-loe07:/# /usr/bin/amqp-publish --url=$BROKER_URL -r foo -p -b Hello
|
||||
|
||||
# 다시 메시지를 돌려받는다.
|
||||
|
||||
root@temp-loe07:/# /usr/bin/amqp-consume --url=$BROKER_URL -q foo -c 1 cat && echo
|
||||
Hello
|
||||
root@temp-loe07:/#
|
||||
```
|
||||
|
||||
마지막 커맨드에서, `amqp-consume` 도구는 대기열로부터 하나의 메시지를
|
||||
받고(`-c 1`), 그 메시지를 임의의 명령 표준입력으로 전달한다. 이 경우에는, `cat` 프로그램이 표준입력으로부터
|
||||
받은 값을 바로 출력하고 있고, echo가 캐리지 리턴을 더해주어
|
||||
출력 결과가 보여진다.
|
||||
|
||||
## 작업으로 대기열 채우기
|
||||
|
||||
이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 간단히 문자열을
|
||||
출력하는 것이다.
|
||||
|
||||
실제로 사용할 때는, 메시지의 내용이 다음과 같을 수 있다.
|
||||
|
||||
- 처리되어야 하는 파일들의 이름
|
||||
- 프로그램의 추가 플래그
|
||||
- 데이터베이스 테이블의 키(key) 범위
|
||||
- 시뮬레이션의 구성 파라미터
|
||||
- 렌더링해야 하는 씬(scene)의 프레임 번호
|
||||
|
||||
실제로는, 잡의 모든 파드에서 읽기-전용 모드로 필요한 큰 데이터가
|
||||
있다면, 일반적으로 그 데이터를 NFS와 같은 공유 파일시스템에 넣고
|
||||
모든 파드에 읽기 전용으로 마운트하거나, 파드 안에 있는 프로그램이 기본적으로 HDFS와 같은
|
||||
클러스터 파일시스템으로부터 데이터를 불러들인다.
|
||||
|
||||
본 예제에서는, 대기열을 만들고 amqp 커맨드라인 도구를 이용해 대기열을 채울 것이다.
|
||||
실제로는, amqp 라이브러리를 이용해 대기열을 채우는 프로그램을 작성하게 된다.
|
||||
|
||||
```shell
|
||||
/usr/bin/amqp-declare-queue --url=$BROKER_URL -q job1 -d
|
||||
job1
|
||||
```
|
||||
```shell
|
||||
for f in apple banana cherry date fig grape lemon melon
|
||||
do
|
||||
/usr/bin/amqp-publish --url=$BROKER_URL -r job1 -p -b $f
|
||||
done
|
||||
```
|
||||
|
||||
8개의 메시지로 대기열을 채웠다.
|
||||
|
||||
## 이미지 생성
|
||||
|
||||
이제 잡으로 실행할 이미지를 만들 준비가 되었다.
|
||||
|
||||
`amqp-consume` 유틸리티를 이용해 대기열로부터 메시지를 읽고,
|
||||
실제 프로그램을 실행해 볼 것이다.
|
||||
여기에 아주 간단한 예제 프로그램이 있다.
|
||||
|
||||
{{< codenew language="python" file="application/job/rabbitmq/worker.py" >}}
|
||||
|
||||
스크립트에 실행 권한을 준다.
|
||||
|
||||
```shell
|
||||
chmod +x worker.py
|
||||
```
|
||||
|
||||
이제 이미지를 빌드한다. 만약 소스 트리 안에서 작업하고
|
||||
있다면, `examples/job/work-queue-1`로 디렉터리를 옮긴다.
|
||||
아니면, 임시 디렉터리를 만들고, 그 디렉터리로 옮긴다.
|
||||
[Dockerfile](/examples/application/job/rabbitmq/Dockerfile)과
|
||||
[worker.py](/examples/application/job/rabbitmq/worker.py)를 다운로드한다.
|
||||
위 두 경우 모두, 다음의 명령을 이용해 이미지를 빌드한다.
|
||||
|
||||
```shell
|
||||
docker build -t job-wq-1 .
|
||||
```
|
||||
|
||||
[도커 허브](https://hub.docker.com/)를 이용하기 위해, 앱 이미지를
|
||||
사용자의 username으로 태깅하고 아래의 명령어를 이용해 허브에 푸시한다.
|
||||
`<username>`을 사용자의 허브 username으로 대체한다.
|
||||
|
||||
```shell
|
||||
docker tag job-wq-1 <username>/job-wq-1
|
||||
docker push <username>/job-wq-1
|
||||
```
|
||||
|
||||
만약 [구글 컨테이너
|
||||
레지스트리](https://cloud.google.com/tools/container-registry/)를 이용하고 있다면,
|
||||
앱 이미지를 사용자의 프로젝트 ID를 이용해 태깅하고, GCR에 푸시한다.
|
||||
`<proejct>` 부분을 사용자의 프로젝트 ID로 대체한다.
|
||||
|
||||
```shell
|
||||
docker tag job-wq-1 gcr.io/<project>/job-wq-1
|
||||
gcloud docker -- push gcr.io/<project>/job-wq-1
|
||||
```
|
||||
|
||||
## 잡 정의
|
||||
|
||||
다음은 잡 정의이다. 잡의 사본을 만들고 위에서 정한 이름에 맞게
|
||||
이미지를 수정하고, 파일 이름을 `./job.yaml`이라 정한다.
|
||||
|
||||
|
||||
{{< codenew file="application/job/rabbitmq/job.yaml" >}}
|
||||
|
||||
이 예시에서는, 각 파드가 대기열로부터 얻은 하나의 아이템을 수행하고 종료한다.
|
||||
그래서, 잡의 완료 횟수가 완료된 작업 아이템의 숫자에 대응한다.
|
||||
예시에서 `.spec.completions: 8`이라 정한 것도, 대기열에 8개의 아이템을 넣었기 때문이다.
|
||||
|
||||
## 잡 실행
|
||||
|
||||
이제 잡을 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./job.yaml
|
||||
```
|
||||
|
||||
이제 조금 기다린 다음, 잡을 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl describe jobs/job-wq-1
|
||||
```
|
||||
```
|
||||
Name: job-wq-1
|
||||
Namespace: default
|
||||
Selector: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
|
||||
Labels: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
|
||||
job-name=job-wq-1
|
||||
Annotations: <none>
|
||||
Parallelism: 2
|
||||
Completions: 8
|
||||
Start Time: Wed, 06 Sep 2017 16:42:02 +0800
|
||||
Pods Statuses: 0 Running / 8 Succeeded / 0 Failed
|
||||
Pod Template:
|
||||
Labels: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
|
||||
job-name=job-wq-1
|
||||
Containers:
|
||||
c:
|
||||
Image: gcr.io/causal-jigsaw-637/job-wq-1
|
||||
Port:
|
||||
Environment:
|
||||
BROKER_URL: amqp://guest:guest@rabbitmq-service:5672
|
||||
QUEUE: job1
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
───────── ──────── ───── ──── ───────────── ────── ────── ───────
|
||||
27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-hcobb
|
||||
27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-weytj
|
||||
27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-qaam5
|
||||
27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-b67sr
|
||||
26s 26s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-xe5hj
|
||||
15s 15s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-w2zqe
|
||||
14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-d6ppa
|
||||
14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-p17e0
|
||||
```
|
||||
|
||||
모든 파드가 성공했다. 야호.
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## 대안
|
||||
|
||||
이러한 접근은 "워커" 프로그램을 작업 대기열에 맞게 수정하지 않아도
|
||||
된다는 장점이 있다.
|
||||
|
||||
이 접근을 이용하려면, 메시지 대기열 서비스를 실행해야만 한다.
|
||||
만약 메시지 대기열 서비스를 실행하는 게 불편하다면,
|
||||
다른 [잡 패턴](/ko/docs/concepts/workloads/controllers/job/#잡-패턴)을 고려해볼 수 있다.
|
||||
|
||||
이 접근은 모든 작업 아이템에 대해 파드를 생성한다. 만약 작업 아이템이 오직 몇 초밖에 걸리지 않는 작업이라면,
|
||||
매 작업마다 파드를 생성하는 것은 아주 큰 오버헤드를 더할 수 있다. 하나의 파드가
|
||||
여러 작업 아이템을 수행하는 이 [예제](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)를 고려해보자.
|
||||
|
||||
이 예제에서는, `amqp-consume` 유틸리티를 이용해 대기열로부터 메시지를 읽어
|
||||
실제 프로그램을 실행했다. 이러면 메시지 대기열을 이용하기 위해 프로그램을 수정하지
|
||||
않아도 된다는 장점이 있다.
|
||||
[다른 예제](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)는
|
||||
클라이언트 라이브러리를 이용해 작업 대기열과 소통하는 방법을 보여준다.
|
||||
|
||||
## 주의 사항
|
||||
|
||||
만약 작업 완료 수가 대기열에 있는 아이템의 숫자보다 적게 설정되면,
|
||||
모든 아이템 처리되지 않는다.
|
||||
|
||||
만약 작업 완료 수가 큐에 있는 아이템의 숫자보다 많게 설정되면,
|
||||
대기열에 있는 아이템이 모두 처리되어도, 잡이 완료됐다고 표시되지
|
||||
않고, 메시지를 기다리는 과정에서 막히는 파드를
|
||||
추가적으로 실행시킨다.
|
||||
|
||||
이 패턴에서는 경쟁 상태(race)가 잘 나타나지 않는다. 만약 amqp-consume 명령으로부터
|
||||
메시지가 인정되는 시간과 컨테이너가 성공적으로 종료되는
|
||||
시간 사이에 컨테이너가 종료되거나, kubelet이 api-server에게 파드가 성공했음을 알리기 전에
|
||||
노드가 비정상적으로 종료되면, 대기열의 모든 아이템이 처리되었다 해도,
|
||||
잡이 완료되었다고 표시되지 않는다.
|
||||
|
|
@ -37,7 +37,7 @@ weight: 30
|
|||
지원한다. 쿠버네티스 오브젝트 타입에 익숙하지 않은 사용자가 인지할 수 있도록 커맨드
|
||||
이름이 지어졌다.
|
||||
|
||||
- `run`: 하나 이상의 파드 내 컨테이너를 실행하도록 새로운 디플로이먼트 오브젝트를 생성한다.
|
||||
- `run`: 컨테이너를 실행할 새로운 파드를 생성한다.
|
||||
- `expose`: 파드에 걸쳐 트래픽을 로드 밸런스하도록 새로운 서비스 오브젝트를 생성한다.
|
||||
- `autoscale`: 디플로이먼트와 같이, 하나의 컨트롤러에 대해 자동으로 수평적 스케일이 이루어 지도록 새로운 Autoscaler 오브젝트를 생성한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -64,6 +64,18 @@ weight: 40
|
|||
|
||||
* `kubectl delete -f <파일명|url>`
|
||||
|
||||
{{< note >}}
|
||||
구성 파일이 `metadata` 섹션에서 `name` 필드 대신 `generateName`
|
||||
필드를 지정한 경우, `kubectl delete -f <filename|url>` 을 사용하여
|
||||
오브젝트를 삭제할 수 없다.
|
||||
오브젝트를 삭제하려면 다른 플래그를 사용해야 한다. 예를 들면, 다음과 같다.
|
||||
|
||||
```shell
|
||||
kubectl delete <type> <name>
|
||||
kubectl delete <type> -l <label>
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
## 오브젝트 확인 방법
|
||||
|
||||
구성파일에 정의한 오브젝트에 관한 정보 확인을 위해 `kubectl get -f`
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ weight: 20
|
|||
<!-- overview -->
|
||||
|
||||
[Kustomize](https://github.com/kubernetes-sigs/kustomize)는
|
||||
[kustomization 파일](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)을
|
||||
[kustomization 파일](https://kubernetes-sigs.github.io/kustomize/api-reference/glossary/#kustomization)을
|
||||
통해 쿠버네티스 오브젝트를 사용자가 원하는 대로 변경하는(customize) 독립형 도구이다.
|
||||
|
||||
1.14 이후로, kubectl도
|
||||
|
|
|
|||
|
|
@ -58,23 +58,15 @@ kubectl create clusterrolebinding cluster-admin-binding \
|
|||
## kube-state-metrics 설치
|
||||
|
||||
[*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)는 쿠버네티스 API 서버를 모니터링하며 오브젝트 상태에 대한 메트릭을 생성하는 간단한 서비스이다. 이런 메트릭을 Metricbeat이 보고한다. 방명록이 실행된 쿠버네티스 클러스터에서 kube-state-metrics을 추가한다.
|
||||
|
||||
### kube-state-metrics 실행 여부 확인
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system | grep kube-state
|
||||
```
|
||||
### 필요하면 kube-state-metrics 설치
|
||||
|
||||
```shell
|
||||
git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics
|
||||
kubectl apply -f kube-state-metrics/examples/standard
|
||||
kubectl get pods --namespace=kube-system | grep kube-state-metrics
|
||||
```
|
||||
kube-state-metrics이 실행 중이고 준비되었는지 확인한다.
|
||||
```shell
|
||||
kubectl get pods -n kube-system -l app.kubernetes.io/name=kube-state-metrics
|
||||
```
|
||||
|
||||
### kube-state-metrics 실행 여부 확인
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics
|
||||
```
|
||||
출력
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: job-wq-1
|
||||
spec:
|
||||
completions: 8
|
||||
parallelism: 2
|
||||
template:
|
||||
metadata:
|
||||
name: job-wq-1
|
||||
spec:
|
||||
containers:
|
||||
- name: c
|
||||
image: gcr.io/<project>/job-wq-1
|
||||
env:
|
||||
- name: BROKER_URL
|
||||
value: amqp://guest:guest@rabbitmq-service:5672
|
||||
- name: QUEUE
|
||||
value: job1
|
||||
restartPolicy: OnFailure
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
#!/usr/bin/env python
|
||||
|
||||
# 표준 출력만 출력하고 10초 동안 대기한다.
|
||||
import sys
|
||||
import time
|
||||
print("Processing " + sys.stdin.readlines()[0])
|
||||
time.sleep(10)
|
||||
|
|
@ -7,7 +7,6 @@ cid: partners
|
|||
---
|
||||
|
||||
<section id="users">
|
||||
<main class="main-section">
|
||||
<h5>쿠버네티스는 파트너와 협력하여 다양하게 보완하는 플랫폼을 지원하는 강력하고 활기찬 코드베이스를 만들어갑니다.</h5>
|
||||
<div class="col-container">
|
||||
<div class="col-nav">
|
||||
|
|
@ -17,7 +16,7 @@ cid: partners
|
|||
</h5>
|
||||
<br>기업들이 쿠버네티스를 성공적으로 채택하도록 도와주는 풍부한 경험을 가진 노련한 서비스 공급자입니다.
|
||||
<br><br><br>
|
||||
<button id="kcsp" class="button" onClick="updateSrc(this.id)">KCSP 파트너 보기</button>
|
||||
<button class="button landscape-trigger landscape-default" data-landscape-types="kubernetes-certified-service-provider" id="kcsp">KCSP 파트너 보기</button>
|
||||
<br><br><a href="https://www.cncf.io/certification/kcsp/">KCSP</a>에
|
||||
관심이 있으신가요?
|
||||
</center>
|
||||
|
|
@ -40,57 +39,13 @@ cid: partners
|
|||
</h5>
|
||||
<br>클라우드 네이티브 기술 교육 경험이 풍부하고 노련한 교육 공급자입니다.
|
||||
<br><br><br>
|
||||
<button id="ktp" class="button" onClick="updateSrc(this.id)">KTP 파트너 보기</button>
|
||||
<button class="button landscape-trigger" data-landscape-types="kubernetes-training-partner" id="ktp">KTP 파트너 보기</button>
|
||||
<br><br><a href="https://www.cncf.io/certification/training/">KTP</a>에
|
||||
관심이 있으신가요?
|
||||
</center>
|
||||
</div>
|
||||
</div>
|
||||
<script crossorigin="anonymous" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" src="https://code.jquery.com/jquery-3.3.1.min.js"></script>
|
||||
<script type="text/javascript">
|
||||
|
||||
var defaultLink = "https://landscape.cncf.io/category=kubernetes-certified-service-provider&format=card-mode&grouping=category&embed=yes";
|
||||
var firstLink = "https://landscape.cncf.io/category=certified-kubernetes-distribution,certified-kubernetes-hosted,certified-kubernetes-installer&format=card-mode&grouping=category&embed=yes";
|
||||
var secondLink = "https://landscape.cncf.io/category=kubernetes-training-partner&format=card-mode&grouping=category&embed=yes";
|
||||
|
||||
function updateSrc(buttonId) {
|
||||
if (buttonId == "kcsp") {
|
||||
$("#landscape").attr("src", defaultLink);
|
||||
window.location.hash = "#kcsp";
|
||||
}
|
||||
if (buttonId == "conformance") {
|
||||
$("#landscape").attr("src", firstLink);
|
||||
window.location.hash = "#conformance";
|
||||
}
|
||||
if (buttonId == "ktp") {
|
||||
$("#landscape").attr("src", secondLink);
|
||||
window.location.hash = "#ktp";
|
||||
}
|
||||
}
|
||||
|
||||
// Automatically load the correct iframe based on the URL fragment
|
||||
document.addEventListener("DOMContentLoaded", function() {
|
||||
var showContent = "kcsp";
|
||||
if (window.location.hash) {
|
||||
console.log("hash is:", window
|
||||
.location
|
||||
.hash
|
||||
.substring(1));
|
||||
showContent = window
|
||||
.location
|
||||
.hash
|
||||
.substring(1);
|
||||
}
|
||||
updateSrc(showContent);
|
||||
});
|
||||
</script>
|
||||
<body>
|
||||
<div id="frameHolder">
|
||||
<iframe frameborder="0" id="landscape" scrolling="no" src="" style="width: 1px; min-width: 100%" title="CNCF Landscape"></iframe>
|
||||
<script src="https://landscape.cncf.io/iframeResizer.js"></script>
|
||||
</div>
|
||||
</body>
|
||||
</main>
|
||||
{{< cncf-landscape helpers=true >}}
|
||||
</section>
|
||||
|
||||
<style>
|
||||
|
|
|
|||
Loading…
Reference in New Issue