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

Fourth Korean localization work for release-1.14 (#14578)

Browse Source 
This commit is the fourth Korean l10n work for release-1.14.

Change List

* Translate concepts/overview/object-management-kubectl/declarative-config in Korean (#14285)

* translate cron-jobs.md to korean + add _index.md (#14024)

* ko: update outdated files in dev-1.14-ko.4 #14207 (#14347)

* Translate standardized glossary Tag Workload in Korean (#14208)

* translate to content/ko/docs/concepts/cluster-administration/controll… (#14234)

* ko: update concepts, contribute, tasks in dev-1.14-ko.4 #14207 (#14502)

* ko: update cheatsheet in dev-1.14-ko.4  (#14515)

Co-Authored-By:    Woojin Na(Eddie) <kimchigood1130@gmail.com>
Co-Authored-By:    Kim Young Dae <38598117+zer0big@users.noreply.github.com>
Co-Authored-by:    Claudia J. Kang <claudiajkang@gmail.com>
Co-authored-by:    Yoon <learder@gmail.com>
Co-authored-by:    June Yi <june.yi@samsung.com>
Co-authored-by:    Seokho <shsongist@gmail.com>
This commit is contained in:
June Yi
2019-05-29 00:30:00 +09:00
committed by Kubernetes Prow Robot
parent 7841f8b24b
commit b19c549355
25 changed files with 1721 additions and 381 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/overview/components.md
+12 -8
View File
@@ -16,7 +16,7 @@ card:
## 마스터 컴포넌트
마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정
(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(레플리케이션 컨트롤러의 '레플리카' 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.
(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.
마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나,
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고,
@@ -72,19 +72,21 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
### kube-proxy
[kube-proxy](/docs/admin/kube-proxy/)는 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로서 쿠버네티스 서비스 추상화가 가능하도록 해준다.
[kube-proxy](/docs/admin/kube-proxy/)는 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로서
쿠버네티스 서비스 추상화가 가능하도록 해준다.
### 컨테이너 런타임
컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다.
컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다.
쿠버네티스는 몇몇의 런타임을 지원하는데 [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) 그리고 [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 런타임이다.
## 애드온
애드온은 클러스터 기능을 이행하는 파드와 서비스다. 이 파드는 디플로이먼트, 레플리케이션 컨트롤러, 기타 등등에 의해 관리될 수도 있다. 네임스페이스를 갖는 애드온 오브젝트는 `kube-system` 네임스페이스 내에서 생성되어 진다.
애드온은 클러스터 기능을 이행하는 파드와 서비스다.
이 파드는 디플로이먼트, 레플리케이션 컨트롤러, 기타 등등에 의해 관리될 수도 있다.
네임스페이스를 갖는 애드온 오브젝트는 `kube-system` 네임스페이스 내에서 생성되어 진다.
선택된 일부 애드온이 아래에 설명되었으며, 사용가능한 전체 확장 애드온 리스트는
[애드온](/docs/concepts/cluster-administration/addons/)을 참조한다.
선택된 일부 애드온이 아래에 설명되었으며, 사용가능한 전체 확장 애드온 리스트는 [애드온](/docs/concepts/cluster-administration/addons/)을 참조한다.
### DNS
@@ -100,11 +102,13 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
### 컨테이너 리소스 모니터링
[컨테이너 리소스 모니터링](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은 중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 메트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
[컨테이너 리소스 모니터링](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은
중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 메트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
### 클러스터-레벨 로깅
[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다.
[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은
검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다.
{{% /capture %}}
content/ko/docs/concepts/overview/object-management-kubectl/declarative-config.md
+990
View File
@@ -0,0 +1,990 @@
---
title: 구성 파일을 이용한 쿠버네티스 오브젝트의 선언형 관리
content_template: templates/concept
weight: 40
---
{{% capture overview %}}
쿠버네티스 오브젝트는 여러 개의 오브젝트 구성 파일을
디렉터리에 저장하고 필요에 따라 `kubectl apply`를
사용하여 재귀적으로 오브젝트를 생성하고 업데이트함으로써 생성, 업데이트 및 삭제할 수 있다.
이 방식은 변경사항을 되돌려 오브젝트 구성 파일에 병합하지 않고
활성 오브젝트에 가해진 기록을 유지한다. `kubectl diff`는 또한
`apply`가 어떠한 변경사항을 이루어질지에 대한 프리뷰를 제공한다.
{{% /capture %}}
{{% capture body %}}
## 트레이드 오프
`kubectl` 툴은 세 가지 방식의 오브젝트 관리를 지원한다.
* 명령형 커맨드
* 명령형 오브젝트 구성
* 선언형 오브젝트 구성
오브젝트 관리 방식의 종류별 장단점에 대한 논의는 [Kubernetes Object Management](/docs/concepts/overview/object-management-kubectl/overview/)를
참고한다.
## 시작하기 전에
선언형 오브젝트 구성은 쿠버네티스 오브젝트 정의와
구성에 대한 확실한 이해가 필요하다. 아직 그렇지 못하다면,
먼저 다음 문서를 읽고 이해한다.
- [명령형 커맨드를 사용한 쿠버네티스 오브젝트 관리하기](/ko/docs/concepts/overview/object-management-kubectl/imperative-command/)
- [구성 파일을 사용한 쿠버네티스 오브젝트 명령형 관리](/ko/docs/concepts/overview/object-management-kubectl/imperative-config/)
다음은 이 문서에서 사용되는 용어에 대한 정의이다.
- *오브젝트 구성 파일 / 구성 파일*: 쿠버네티스 오브젝트에 대한
구성을 정의하는 하나의 파일. 이 주제는 어떻게
`kubectl apply`에 구성 파일을 전달하는지에 대해 보여준다. 구성 파일은 일반적으로 Git과 같은, 소스 컨트롤에 저장된다.
- *활성 오브젝트 구성 / 활성 구성*: 쿠버네티스 클러스터에 의해 관측된
오브젝트에 대한 활성 구성 값. 이것들은 쿠버네티스 클러스터 저장소에 유지된다.
일반적으로 etcd가 사용된다.
- *선언형 구성 작성자 / 선언형 작성자*: 활성 오브젝트를 업데이트해 주는
사람이나 소프트웨어. 이 주제에서 언급하는 활성 작성자는 오브젝트 구성 파일에 변경을 가하고
`kubectl apply`를 실행하여 변경사항을 기록한다.
## 오브젝트 생성 방법
기존에 존재하는 것을 제외한, 지정한 디렉터리 내 구성 파일에 의해 정의된 모든 오브젝트를 생성하기 위해 `kubectl apply`를
사용한다.
```shell
kubectl apply -f <디렉터리>/
```
이것은  각 오브젝트에 대해 `kubectl.kubernetes.io/last-applied-configuration: '{...}'`
어노테이션을 설정한다. 해당 어노테이션은 오브젝트를 생성하기 위해 사용했던
오브젝트 구성 파일의 내용을 포함한다. 
{{< note >}}
재귀적으로 디렉터리를 처리하기 위해서 `-R` 플래그를 추가한다. 
{{< /note >}}
다음은 오브젝트 구성 파일에 대한 예시이다.
{{< codenew file="application/simple_deployment.yaml" >}}
생성될 오브젝트를 출력하려면 `kubectl diff`를 실행한다. 
```shell
kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml
```
{{< note >}}
`diff`는 `kube-apiserver`의 활성화가 필요한 [서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다.
{{< /note >}}
`kubectl apply`를 사용하여 오브젝트를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
```
`kubectl get`을 사용하여 활성 구성을 출력한다.
```shell
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
```
출력은 `kubectl.kubernetes.io/last-applied-configuration` 어노테이션이
활성 구성에 기록된 것을 보여주며, 그것은 구성 파일과 일치한다.
```yaml
kind: Deployment
metadata:
annotations:
# ...
# This is the json representation of simple_deployment.yaml
# It was written by kubectl apply when the object was created
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}
# ...
spec:
# ...
minReadySeconds: 5
selector:
matchLabels:
# ...
app: nginx
template:
metadata:
# ...
labels:
app: nginx
spec:
containers:
- image: nginx:1.7.9
# ...
name: nginx
ports:
- containerPort: 80
# ...
# ...
# ...
# ...
```
## How to update objects
또한 오브젝트가 기존에 존재하더라도 디렉터리 내 정의된 모든 오브젝트를 업데이트하기 위해 `kubectl apply`를
사용할 수 있다. 이러한 접근방식은 다음을 수행할 수 있게 해준다.
1. 활성 구성 내 구성 파일에 나타나는 필드 설정
2. 활성 구성 내 구성 파일로부터 제거된 필드 정리
```shell
kubectl diff -f <디렉터리>/
kubectl apply -f <디렉터리>/
```
{{< note >}}
재귀적으로 디렉터리를 처리하기 위해서 `-R`플래그를 추가한다.
{{< /note >}}
다음은 구성 파일의 예시이다.
{{< codenew file="application/simple_deployment.yaml" >}}
`kubectl apply`를 사용하여 오브젝트를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
```
{{< note >}}
설명을 위해, 앞선 명령은 디렉터리 대신
하나의 구성 파일을 참조한다.
{{< /note >}}
`kubectl get`을 사용하여 활성 구성을 출력한다.
```shell
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
```
출력은 `kubectl.kubernetes.io/last-applied-configuration` 어노테이션이
활성 구성에 기록된 것을 보여주며, 그것은 구성 파일과 일치한다.
```yaml
kind: Deployment
metadata:
annotations:
# ...
# This is the json representation of simple_deployment.yaml
# It was written by kubectl apply when the object was created
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}
# ...
spec:
# ...
minReadySeconds: 5
selector:
matchLabels:
# ...
app: nginx
template:
metadata:
# ...
labels:
app: nginx
spec:
containers:
- image: nginx:1.7.9
# ...
name: nginx
ports:
- containerPort: 80
# ...
# ...
# ...
# ...
```
`kubectl scale`을 사용하여 활성 구성 내 `replicas` 필드를 직접 업데이트한다.
이는 `kubectl apply`를 사용하지 않는다.
```shell
kubectl scale deployment/nginx-deployment --replicas=2
```
`kubectl get`을 사용하여 활성 구성을 출력한다.
```shell
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
```
출력은 `replicas` 필드가 2로 설정된 것을 보여주며, `last-applied-configuration`
어노테이션은 `replicas` 필드를 포함하지 않는다.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
# ...
# note that the annotation does not contain replicas
# because it was not updated through apply
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}
# ...
spec:
replicas: 2 # written by scale
# ...
minReadySeconds: 5
selector:
matchLabels:
# ...
app: nginx
template:
metadata:
# ...
labels:
app: nginx
spec:
containers:
- image: nginx:1.7.9
# ...
name: nginx
ports:
- containerPort: 80
# ...
```
`nginx:1.7.9`에서 `nginx:1.11.9`로 이미지를 변경하기 위해 `simple_deployment.yaml`
구성 파일을 업데이트 하고, `minReadySeconds` 필드를 삭제한다.
{{< codenew file="application/update_deployment.yaml" >}}
구성 파일에 이루어진 변경사항을 적용한다.
```shell
kubectl diff -f https://k8s.io/examples/application/update_deployment.yaml
kubectl apply -f https://k8s.io/examples/application/update_deployment.yaml
```
`kubectl get`을 사용하여 활성 구성을 출력한다.
```
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
```
출력은 활성 구성에 다음의 변경사항을 보여준다.
- `replicas` 필드는 `kubectl scale`에 의해 설정된 값 2를 유지한다.
이는 구성 파일에서 생략되었기 때문에 가능하다.
- `image` 필드는 `nginx:1.7.9`에서 `nginx:1.11.9`로 업데이트되었다.
- `last-applied-configuration` 어노테이션은 새로운 이미지로 업데이트되었다.
- `minReadySeconds` 필드는 지워졌다.
- `last-applied-configuration` 어노테이션은 더 이상 `minReadySeconds` 필드를 포함하지 않는다.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
# ...
# The annotation contains the updated image to nginx 1.11.9,
# but does not contain the updated replicas to 2
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}
# ...
spec:
replicas: 2 # Set by `kubectl scale`. Ignored by `kubectl apply`.
# minReadySeconds cleared by `kubectl apply`
# ...
selector:
matchLabels:
# ...
app: nginx
template:
metadata:
# ...
labels:
app: nginx
spec:
containers:
- image: nginx:1.11.9 # Set by `kubectl apply`
# ...
name: nginx
ports:
- containerPort: 80
# ...
# ...
# ...
# ...
```
{{< warning >}}
명령형 오브젝트 구성 커맨드 `create`와 `replace`와 함께 `kubectl apply`를
혼합하는 것은 지원하지 않는다. 이는 `kubectl apply`가 업데이트 사항을 계산하는데 사용하는
`kubectl.kubernetes.io/last-applied-configuration`을 `create`와 `replace`가
유지하지 하지 않기 때문이다.
{{< /warning >}}
## 오브젝트 삭제 방법
`kubectl apply`에 의해 관리되는 오브젝트를 삭제하는데 2가지 접근 방법이 있다.
### 권장 방법: `kubectl delete -f <파일명>`
명령형 커맨드를 사용하여 오브젝트를 수동으로 삭제하는 것이 권장되는 방식인데,
무엇이 삭제되는지에 대해 더 명확하게 나타내므로 사용자가 의도하지 않게
무언가를 삭제할 가능성이 작아지기 때문이다.
```shell
kubectl delete -f <파일명>
```
### 대안: `kubectl apply -f <디렉터리/> --prune -l your=레이블`
무엇을 하는지 파악하는 경우에만 이를 사용한다.
{{< warning >}}
`kubectl apply --prune`은 알파 상태이며, 후속 릴리스에서는
하위 호환되지 않는 변경 사항이 도입될 수 있다.
{{< /warning >}}
{{< warning >}}
이 명령을 사용할 때는 의도하지 않게 오브젝트를 삭제하지 않도록
주의해야만 한다.
{{< /warning >}}
`kubectl delete`에 대한 대안으로, 디렉터리로부터 구성 파일이 삭제된 후에 삭제될 오브젝트를 식별하기 위해 `kubectl apply`를 사용할 수 있다.
`--prune`을 사용하여 적용하면 일련의 레이블의 집합과 일치하는
모든 오브젝트에 대해API 서버에 쿼리하고, 반환된 활성 오브젝트
구성을 오브젝트 구성 파일에 일치시키려고 시도한다.
오브젝트가 쿼리에 일치하고, 해당 디렉터리 내 구성 파일이 없고
`last-applied-configuration`어노테이션이 있는 경우,
삭제된다.
{{< comment >}}
TODO(pwittrock): We need to change the behavior to prevent the user from running apply on subdirectories unintentionally.
{{< /comment >}}
```shell
kubectl apply -f <디렉터리/> --prune -l <레이블>
```
{{< warning >}}
prune을 사용하여 적용하는 것은 오브젝트 구성 파일을
포함하는 루트 디렉터리에 대해서만 실행해야 한다.
하위 디렉터리에 대해 실행하게 되면,
`-l <레이블>`로 지정된 레이블 셀렉터에 의해 반환되고 하위 디렉터리에 나타나지 않는 경우,
오브젝트가 의도하지 않게 삭제될 수 있다.
{{< /warning >}}
## 오브젝트 확인 방법
활성 오브젝트의 구성을 확인하기 위해 `-o yaml`과 함께 `kubectl get`을 사용할 수 있다.
```shell
kubectl get -f <파일명|url> -o yaml
```
## 어떻게 apply가 차이를 계산하고 변경을 병합하는가
{{< caution >}}
*patch* 는 전체 오브젝트 대신 오브젝트의 특정 필드 범위의 오퍼레이션을 업데이트한다.
이는 먼저 오브젝트를 읽지 않고도 오브젝트의 특정 필드 집합만을
업데이트할 수 있도록 해준다.
{{< /caution >}}
`kubectl apply`가 하나의 오브젝트에 대한 활성 구성을 업데이트할 때,
API 서버에 패치 요청을 보냄으로써 그것을 수행한다.
그 패치는 활성 오브젝트 구성의 특정 필드에 대한 범위의
업데이트로 한정한다. `kubectl apply` 커맨드는
구성 파일, 활성 구성, 그리고 활성 구성에 저장된
`last-applied-configuration`어노테이션을 사용하여 이 패치 요청을 계산한다.
### 패치 계산 병합
`kubectl apply` 명령은
`kubectl.kubernetes.io/last-applied-configuration` 어노테이션에 구성 파일의 내용을 기록한다.
이것은 구성 파일로부터 제거되었고 활성 구성으로부터 지워질 필요가 있는
필드를 확인하는 데 사용된다. 다음은 어떤 필드가 삭제 또는 설정돼야 하는지
계산하기 위해 사용되는 단계이다.
1. 삭제할 필드를 계산한다. 이것은 `last-applied-configuration` 내 존재하고 구성 파일로부터 유실된 필드이다.
2. 추가 또는 설정되어야 할 필드를 계산한다. 이것은 활성 구성과 불일치하는 값을 가지는 구성 파일 내 존재하는 필드이다.
다음은 예시이다. 디플로이먼트 오브젝트에 대한 구성 파일이라고 가정한다.
{{< codenew file="application/update_deployment.yaml" >}}
또한, 이것은 동일한 디플로이먼트 오브젝트에 대한 활성 구성이라고 가정한다.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
# ...
# note that the annotation does not contain replicas
# because it was not updated through apply
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}
# ...
spec:
replicas: 2 # written by scale
# ...
minReadySeconds: 5
selector:
matchLabels:
# ...
app: nginx
template:
metadata:
# ...
labels:
app: nginx
spec:
containers:
- image: nginx:1.7.9
# ...
name: nginx
ports:
- containerPort: 80
# ...
```
다음은 `kubectl apply`에 의해 수행될 병합 계산이다.
1. `last-applied-configuration`으로부터 값을 읽어
구성 파일의 값과 비교하여 삭제할 필드를
계산한다.
`last-applied-configuration`에 보이는 것과는 무관하게
로컬의 오브젝트 구성 파일 내 null이라고 명시적으로 설정된 필드를 지운다.
이 예시에서, `minReadySeconds`은
`last-applied-configuration` 어노테이션 내 나타나지만, 구성 파일 내에는 보여지지 않는다.
**조치:** 활성 구성으로부터 `minReadySeconds`을 지운다.
2. 구성 파일로부터 값을 읽어 활성 구성 내 값과
비교하여 설정할 필드를 계산한다. 이 예시에서,
구성 파일 내 `image` 값은 활성 구성 내 값과 불일치한다.
**조치:** 활성 구성 내 `image` 값을 설정한다.
3. 구성 파일의 값과 일치시키기 위해 `last-applied-configuration`
어노테이션을 설정한다.
4. 1, 2, 3으로부터의 결과를 API 서버에 단일 패치 요청으로 병합한다.
다음은 병합의 결과인 활성 구성이다.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
# ...
# The annotation contains the updated image to nginx 1.11.9,
# but does not contain the updated replicas to 2
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}
# ...
spec:
selector:
matchLabels:
# ...
app: nginx
replicas: 2 # Set by `kubectl scale`. Ignored by `kubectl apply`.
# minReadySeconds cleared by `kubectl apply`
# ...
template:
metadata:
# ...
labels:
app: nginx
spec:
containers:
- image: nginx:1.11.9 # Set by `kubectl apply`
# ...
name: nginx
ports:
- containerPort: 80
# ...
# ...
# ...
# ...
```
### 어떻게 상이한 필드 타입이 병합되는가
구성 파일 내 특정 필드가 필드의 타입에 따라
어떻게 활성 구성과 함께 병합되는가.
여러 가지 필드 타입이 있다.
- *기본(primitives)*: 문자열, 숫자 또는 불리언 타입의 필드.
예를 들어, `image`와 `replicas`는 기본 필드다. **조치:** 교체.
- *맵*, 또한 *오브젝트* 라 칭함: 맵 타입 또는 서브필드를 포함하는 복합 타입의 필드. 예를 들어, `레이블`,
`어노테이션`,`스펙` 및 `메타데이터`는 모두 맵이다. **조치:** 구성요소 또는 서브필드 병합.
- *리스트*: 기본타입 또는 맵이 될 수 있는 아이템의 리스트를 포함하는 필드.
예를 들어, `컨테이너`, `포트`, 그리고 `args`는 리스트다. **조치:** 다양함.
`kubectl apply`가 맵 또는 리스트 필드를 업데이트하는 경우,
일반적으로 전체 필드를 교체하는 대신, 개별 부 구성요소를 업데이트한다,
예를 들어, 디플로이먼트에 대한 `spec`을 병합할 경우, 전체 `spec`이
교체되지 않는다. 대신 `replicas`와 같은 `spec`의 서브필드가
비교되고 병합된다.
### 기본 필드에 대한 변경사항 병합하기
기본 필드는 교체되거나 지워진다.
{{< note >}}
`-` 는 값이 사용되지 않기 때문에 "해당 없음"으로 사용된다.
{{< /note >}}
| Field in object configuration file | Field in live object configuration | Field in last-applied-configuration | Action |
|-------------------------------------|------------------------------------|-------------------------------------|-------------------------------------------|
| Yes | Yes | - | 구성 파일 값 활성으로 설정. |
| Yes | No | - | 활성을 로컬 구성으로 설정. |
| No | - | Yes | 활성 구성으로부터 지움. |
| No | - | No | 아무것도 안함. 활성값 유지. |
### 맵 필드에 변경사항 병합하기
맵을 요청하는 필드는 서브필드의 각각 또는 맵의 구성요소를 비교함으로써 병합된다.
{{< note >}}
`-` 는 값이 사용되지 않기 때문에 "해당 없음"으로 사용된다.
{{< /note >}}
| Key in object configuration file | Key in live object configuration | Field in last-applied-configuration | Action |
|-------------------------------------|------------------------------------|-------------------------------------|----------------------------------|
| Yes | Yes | - | 서브필드 값 비교. |
| Yes | No | - | 활성을 로컬 구성으로 설정. |
| No | - | Yes | 활성 구성으로부터 삭제. |
| No | - | No | 아무것도 안함. 활성값 유지. |
### 타입 리스트의 필드에 대한 변경사항 병합하기
리스트에 대한 변경사항을 병합하는 것은 세 가지 전략 중 하나를 사용한다.
* 구성요소가 모두 기본형인 경우 리스트를 교체한다.
* 복합 구성요소의 리스트에서 개별 구성요소를 병합한다.
* 기초 구성요소의 리스트를 병합한다.
전략에 대한 선택은 필드별로 이루어진다.
#### 구성요소가 모두 기본형인 경우 리스트 교체
기초 필드와 동일한 리스트로 취급한다. 전체 리스트를 교체 또는 삭제한다.
이것은 순서를 유지한다.
**예시:** 파드 내 컨테이너의 `args` 필드를 업데이트하기 위해 `kubectl apply`를 사용한다.
이것은 활성 구성 내 `args`의 값을 구성 파일 내 값으로 설정한다.
활성 구성에 추가했던 이전의 모든 `args`구성요소들은 유실된다.
구성 파일 내 정의한 `args` 구성요소의 순서는
활성 구성 내 유지된다.
```yaml
# last-applied-configuration value
args: ["a", "b"]
# configuration file value
args: ["a", "c"]
# live configuration
args: ["a", "b", "d"]
# result after merge
args: ["a", "c"]
```
**설명:** 병합은 새로운 리스트 값으로 구성 파일 값을 사용했다.
#### 복합 구성요소 리스트에 대한 개별 구성요소 병합
리스트를 맵으로 취급하고 각 구성요소의 특정 필드를 키로 취급한다.
개별 구성요소를 추가, 삭제, 또는 업데이트 한다. 이것은 순서를 보존하지 않는다.
이 병합 전략은 각 필드에 `patchMergeKey`라 칭하는 특별한 태그를 사용한다.
`patchMergeKey`는 쿠버네티스 소스 코드:
[types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2747)
의 각 필드에 대해 정의한다. 맵 리스트를 병합할 때, 주어진 구성요소에 대한 `patchMergeKey`로
지정한 필드는 해당 구성요소에 대한 맵키와 같이 사용된다.
**예시:** `kubectl apply`를 사용하여 PodSpec에 대한 `containers`필드를 업데이트한다.
이렇게 하면 각 구성요소가
`name`별로 키로 되어 있는 맵인 것처럼 리스트를 병합한다.
```yaml
# last-applied-configuration value
containers:
- name: nginx
image: nginx:1.10
- name: nginx-helper-a # key: nginx-helper-a; will be deleted in result
image: helper:1.3
- name: nginx-helper-b # key: nginx-helper-b; will be retained
image: helper:1.3
# configuration file value
containers:
- name: nginx
image: nginx:1.10
- name: nginx-helper-b
image: helper:1.3
- name: nginx-helper-c # key: nginx-helper-c; will be added in result
image: helper:1.3
# live configuration
containers:
- name: nginx
image: nginx:1.10
- name: nginx-helper-a
image: helper:1.3
- name: nginx-helper-b
image: helper:1.3
args: ["run"] # Field will be retained
- name: nginx-helper-d # key: nginx-helper-d; will be retained
image: helper:1.3
# result after merge
containers:
- name: nginx
image: nginx:1.10
# Element nginx-helper-a was deleted
- name: nginx-helper-b
image: helper:1.3
args: ["run"] # Field was retained
- name: nginx-helper-c # Element was added
image: helper:1.3
- name: nginx-helper-d # Element was ignored
image: helper:1.3
```
**설명:**
- 구성 파일에 "nginx-helper-a"라는 이름을 가진 컨테이너가 나타나지 않았기 때문에
"nginx-helper-a"라는 컨테이너는 삭제되었다.
- "nginx-helper-b"라는 컨테이너는 활성 구성에 `args`에
대한 변경사항을 유지했다. `kubectl apply`는
필드 값이 다름에도 불구하고(구성 파일에 `args`가 없음) 활성 구성에
"nginx-helper-b"가 구성 파일과 동일한
"nginx-helper-b"임을 식별할 수 있었다. 이것은
`patchMergeKey` 필드 값(이름)이 둘 다 같았기 때문이다..
- "nginx-helper-c"라는 이름의 컨테이너가 활성 구성에 나타나지
않았지만, 구성 파일에 그 이름을 가진 컨테이너가 나타났기 때문에
추가되었다.
- last-applied-configuration에 그 이름을 가진 구성요소가 없었기 때문에
"nginx-helper-d"라는 이름의 컨테이너는 유지되었다.
#### 기초 구성요소 리스트 병합
쿠버네티스 1.5로부터 기초 구성요소 병합하기는 지원되지 않는다.
{{< note >}}
주어진 필드에 대해 위 전략 중 어떤 것을 선택할지에 대해서는
[types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2748)의 `patchStrategy` 태그에 의해 제어된다.
타입 필드에 대해 `patchStrategy`가 지정되지 않으면,
리스트는 대체된다.
{{< /note >}}
{{< comment >}}
TODO(pwittrock): Uncomment this for 1.6
- Treat the list as a set of primitives. Replace or delete individual
elements. Does not preserve ordering. Does not preserve duplicates.
**Example:** Using apply to update the `finalizers` field of ObjectMeta
keeps elements added to the live configuration. Ordering of finalizers
is lost.
{{< /comment >}}
## 기본 필드값
오브젝트가 생성될 때 값이 지정되지 않는 경우, API 서버는 활성 구성 내
특정 필드를 기본값으로 설정한다.
다음은 디플로이먼트에 대한 구성 파일이다. 파일에는 `strategy`가 지정되지 않았다.
{{< codenew file="application/simple_deployment.yaml" >}}
`kubectl apply`를 사용하여 오브젝트를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
```
`kubectl get`을 사용하여 활성 구성을 출력한다.
```shell
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
```
출력은 API 서버가 활성 구성 내 여러 필드를 기본값으로 설정한 것을 보여준다.
이 필드들은 구성 파일에 지정되지 않았다.
```yaml
apiVersion: apps/v1
kind: Deployment
# ...
spec:
selector:
matchLabels:
app: nginx
minReadySeconds: 5
replicas: 1 # defaulted by apiserver
strategy:
rollingUpdate: # defaulted by apiserver - derived from strategy.type
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate # defaulted apiserver
template:
metadata:
creationTimestamp: null
labels:
app: nginx
spec:
containers:
- image: nginx:1.7.9
imagePullPolicy: IfNotPresent # defaulted by apiserver
name: nginx
ports:
- containerPort: 80
protocol: TCP # defaulted by apiserver
resources: {} # defaulted by apiserver
terminationMessagePath: /dev/termination-log # defaulted by apiserver
dnsPolicy: ClusterFirst # defaulted by apiserver
restartPolicy: Always # defaulted by apiserver
securityContext: {} # defaulted by apiserver
terminationGracePeriodSeconds: 30 # defaulted by apiserver
# ...
```
패치 요청에서, 패치 요청의 부분으로서 명시적으로 지워지지 않은 경우
기본 처리된 필드는 다시 기본으로 설정되지 않는다.
이것은 다른 필드에 대한 값에 따라 기본 처리된 필드에 대해
예상하지 못한 동작을 유발할 수 있다. 다른 필드가 나중에 변경되면,
그로부터 기본 처리된 것이 명시적으로 지워지지 않은 한
업데이트되지 않을 것이다.
이러한 사유로, 의도한 값이 서버의 기본값과 일치하더라도,
서버에 의해 기본 처리된 특정 필드는 구성 파일 내
명시적으로 정의할 것을 권고한다. 이렇게 하면
서버에 의해 다시 기본 처리되지 않게 될 충돌하는 값을 보다 쉽게
인식할 수 있도록 해준다.
**Example:**
```yaml
# last-applied-configuration
spec:
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
# configuration file
spec:
strategy:
type: Recreate # updated value
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
# live configuration
spec:
strategy:
type: RollingUpdate # defaulted value
rollingUpdate: # defaulted value derived from type
maxSurge : 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
# result after merge - ERROR!
spec:
strategy:
type: Recreate # updated value: incompatible with rollingUpdate
rollingUpdate: # defaulted value: incompatible with "type: Recreate"
maxSurge : 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
```
**설명:**
1. 사용자가 `strategy.type`을 정의하지 않고 디플로이먼트를 생성한다.
2. 서버는 `strategy.type`을 `RollingUpdate`로 기본 설정하고
`strategy.rollingUpdate`값을 기본 값으로 처리한다.
3. 사용자가 `strategy.type`를 `Recreate`로 변경한다.
서버에서 해당 값이 삭제될 거라 예상하지만 `strategy.rollingUpdate`값은 기본값으로 남아 있다.
`strategy.rollingUpdate`값이 처음에 구성 파일에서 지정되었다면,
이것을 삭제해야 한다는 것이 더 분명했을 것이다.
4. `strategy.rollingUpdate`가 지워지지 않았기 때문에 적용은 실패한다.
`strategy.rollingupdate` 필드는 `Recreate`의 `strategy.type`으로 정의될 수 없다.
권고: 이들 필드는 오브젝트 구성 파일 내 명시적으로 정의돼야 한다.
- 디플로이먼트, 스테이트풀셋, 잡, 데몬셋, 레플리카셋 및 레플리케이션컨트롤러와 같은
워크로드에 대한 셀렉터와 파드템플릿 레이블
- 디플로이먼트 롤아웃 전략
### 서버 기본 필드 또는 다른 작성자에 의해 설정된 필드 지우는 방법
구성 파일 내 나타나지 않는 필드는 그 값을
`null`로 설정하고 나서 구성 파일을 적용함으로써 지워질 수 있다.
서버가 기본 값을 할당했던 필드에 대해서, 이는 다시 기본 값을
할당하도록 한다.
## 구성 파일과 직접 명령형 작성자 간의 필드 소유권을 변경시키는 방법
개별 오브젝트 필드를 변경시키는 데 사용해야 하는 유일한 방법은 다음과 같다.
- `kubectl apply`를 사용한다.
- 구성 파일을 수정하지 않고 활성 구성을 직접 작성한다.
예를 들어, `kubectl scale`을 사용한다.
### 직접 명령형 작성자에서 구성 파일로 소유자 변경하기
구성 파일에 필드를 추가한다. 해당 필드의 경우
`kubectl apply`를 거치지 않는 활성 구성에 대해 직접 업데이트를 적용하지 않는다.
### 구성 파일에서 직접 명령형 작성자로 소유자 변경하기
쿠버네티스 1.5로부터 구성 파일에서 명령형 작성자로 소유권을 변경하는데
수동 단계 필요하다.
- 구성 파일에서 필드를 제거한다.
- 활성 오브젝트 상의 `kubectl.kubernetes.io/last-applied-configuration` 어노테이션에서 필드를 제거한다.
## 관리 방법 변경하기
쿠버네티스 오브젝트는 한 번에 오직 하나의 방법을 사용하여 관리돼야 한다.
하나의 방법에서 다른 방법으로 전환하는 것은 가능하나, 수동 프로세스이다.
{{< note >}}
선언형 관리와 함께 명령형 삭제를 사용하는 것은 괜찮다.
{{< /note >}}
{{< comment >}}
TODO(pwittrock): We need to make using imperative commands with
declarative object configuration work so that it doesn't write the
fields to the annotation, and instead. Then add this bullet point.
- using imperative commands with declarative configuration to manage where each manages different fields.
{{< /comment >}}
### 명령형 커맨드 관리에서 오브젝트 구성으로 이전하기
명령형 커맨드 관리에서 오브젝트 구성으로 이전하는 것은
여러 수동 단계를 포함한다.
1. 활성 오브젝트를 로컬 구성 파일로 내보낸다.
```shell
kubectl get <종류>/<이름> -o yaml --export > <종류>_<이름>.yaml
```
1. 구성 파일에서 수동으로 `status` 필드를 제거한다.
{{< note >}}
`kubectl apply` 구성 파일에 존재한다고 하더라도 상태 필드가 업데이트되지 않기 때문에,
이 단계는 선택적이다.
{{< /note >}}
1. 오브젝트의 `kubectl.kubernetes.io/last-applied-configuration` 어노테이션을 설정한다.
```shell
kubectl replace --save-config -f <종류>_<이름>.yaml
```
1. 오직 오브젝트를 관리하기 위해 `kubectl apply`를 사용하도록 프로세스를 변경한다.
{{< comment >}}
TODO(pwittrock): Why doesn't export remove the status field? Seems like it should.
{{< /comment >}}
### 명령형 오브젝트 구성에서 선언형 오브젝트 구성으로 이전하기
1. 오브젝트의 `kubectl.kubernetes.io/last-applied-configuration` 어노테이션을 설정한다.
```shell
kubectl replace --save-config -f <종류>_<이름>.yaml
```
1. 오직 오브젝트를 관리하기 위해 `kubectl apply`를 사용하도록 프로세스를 변경한다.
## 컨트롤러 셀렉터와 파드템플릿 레이블 정의하기
{{< warning >}}
컨트롤러에서 셀렉터를 업데이트하는 것은 추천되지 않는다.
{{< /warning >}}
권고되는 접근 방법은 다른 의미론적 의미를 가지지 않고 컨트롤러에 의해서만 사용되는
단일, 불변의 파드템플릿 레이블을 정의하는 것이다.
**예시:**
```yaml
selector:
matchLabels:
controller-selector: "extensions/v1beta1/deployment/nginx"
template:
metadata:
labels:
controller-selector: "extensions/v1beta1/deployment/nginx"
```
{{% capture whatsnext %}}
- [명령형 커맨드 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/concepts/overview/object-management-kubectl/imperative-command/)
- [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/concepts/overview/object-management-kubectl/imperative-config/)
- [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/)
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}
content/ko/docs/concepts/overview/what-is-kubernetes.md
+89 -61
View File
@@ -1,5 +1,5 @@
---
title: 쿠버네티스란 무엇인가?
title: 쿠버네티스란 무엇인가
content_template: templates/concept
weight: 10
card:
@@ -17,12 +17,13 @@ card:
용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다.
쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.
구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 [구글의
15여년에 걸친 대규모 운영 워크로드 운영
경험](https://research.google.com/pubs/pub43438.html)을 기반으로 만들어졌으며
구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다.
쿠버네티스는
[구글의 15여년에 걸친 대규모 상용 워크로드 운영 경험](https://research.google.com/pubs/pub43438.html)을
기반으로 만들어졌으며
커뮤니티의 최고의 아이디어와 적용 사례가 결합되었다.
## 쿠버네티스가 왜 필요하고 무엇을 할 수 있는가?
## 쿠버네티스가 왜 필요하고 무엇을 할 수 있는가
쿠버네티스에는 많은 기능이 있다. 다음과 같이 생각해 볼 수 있다.
@@ -31,45 +32,55 @@ card:
- 이식성 있는 클라우드 플랫폼
그리고 더 많은 기능.
쿠버네티스는 **컨테이너 중심의** 관리 환경을 제공한다. 이 환경은 사용자
워크로드를 위해서 컴퓨팅, 네트워킹 및 스토리지 인프라스트럭처를
오케스트레이션한다. 이는 Platform as a Service(PaaS)의 매우 단순명료함에
Infrastructure as a Service (IaaS)의 유연함을 더해 주며, 인프라스트럭처
제공자 간 이식이 가능하게 해준다.
쿠버네티스는 **컨테이너 중심의** 관리 환경을 제공한다.
이 환경은 사용자 워크로드를 위해서
컴퓨팅, 네트워킹 및 스토리지 인프라스트럭처를 오케스트레이션한다.
이는 Platform as a Service(PaaS)의 매우 단순명료함에
Infrastructure as a Service (IaaS)의 유연함을 더해 주며,
인프라스트럭처 제공자 간 이식을 가능하게 한다.
## 어떻게 쿠버네티스가 플랫폼인가
쿠버네티스가 제공하는 많은 기능이 있지만, 신규 기능을 통해 혜택을 얻을 수 있는
새로운 시나리오는 항상 있게 마련이다. 개발자의 생산성을 극대화할 수 있도록
애플리케이션에 특화된 워크플로우를 최적화할 수 있다. 초기에 수용 가능한 애드혹
오케스트레이션은 대규모의 견고한 자동화를 필요로 하곤 한다. 이것이 쿠버네티스가
애플리케이션을 더 쉽게 배포하고, 스케일링하며, 관리하는 컴포넌트와 툴의 생태계를
만드는 플랫폼의 기능을 하도록 설계된 이유이다.
쿠버네티스가 제공하는 많은 기능이 있지만,
신규 기능을 통해 혜택을 얻을 수 있는 새로운 시나리오는 항상 있게 마련이다.
개발자의 생산성을 극대화할 수 있도록 애플리케이션에 특화된 워크플로우를 최적화할 수 있다.
초기에 수용 가능한 애드혹 오케스트레이션은
대규모의 견고한 자동화를 필요로 하곤 한다.
이것이 쿠버네티스가 애플리케이션을 더 쉽게 배포하고,
스케일링하며, 관리하는 컴포넌트와 툴의 생태계를 만드는
플랫폼의 기능을 하도록 설계된 이유이다.
[레이블](/docs/concepts/overview/working-with-objects/labels/)은 사용자가 원하는
방식대로 자원을 정리할 수 있도록 해준다.
[레이블](/docs/concepts/overview/working-with-objects/labels/)은
사용자가 원하는 방식대로 자원을 정리할 수 있도록 해준다.
[어노테이션](/docs/concepts/overview/working-with-objects/annotations/)은
자원에 사용자 정의 정보를 추가해서 사용자의 워크플로우에 활용할 수 있도록 하고
자원에 사용자 정의 정보를 추가해서
사용자의 워크플로우에 활용할 수 있도록 하고
관리 툴이 상태를 쉽게 체크할 수 있는 방법을 제공해 준다.
추가로, [쿠버네티스 컨트롤 플레인](/docs/concepts/overview/components/)은
추가로,
[쿠버네티스 컨트롤 플레인](/docs/concepts/overview/components/)은
개발자와 사용자가 공통으로 사용할 수 있는 [API](/docs/reference/using-api/api-overview/)를
기반으로 하고 있다. 사용자는 범용의 [커맨드라인 툴]((/docs/user-guide/kubectl-overview/))을
기반으로 하고 있다.
사용자는
범용의 [커맨드라인 툴]((/docs/user-guide/kubectl-overview/))을
대상으로 하는 [자체 API](/docs/concepts/api-extension/custom-resources/)를 가진
[스케줄러](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)와
같은 사용자만의 컨트롤러를 작성할 수 있다.
이 [설계](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)를 통해
쿠버네티스 위에 많은 다른 시스템을 올릴 수 있게 된다.
쿠버네티스 위에
많은 다른 시스템을 올릴 수 있게 된다.
## 쿠버네티스가 아닌 것
쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가
아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에,
PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과
같은 기능에서 공통점이 있기도 하다. 하지만, 쿠버네티스는 모놀리식(monolithic)하지
않아서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는
개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과
같은 기능에서 공통점이 있기도 하다.
하지만, 쿠버네티스는 모놀리식(monolithic)하지
않아서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다.
쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만,
필요한 경우 사용자의 선택권과
유연성을 지켜준다.
쿠버네티스는
@@ -80,26 +91,33 @@ PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로
것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서
매우 잘 동작할 것이다.
* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다.
지속적인 통합, 지속적인 배포(Delivery, Deployment)(CI/CD) 워크플로우는
기술적인 요구사항은 물론 조직 문화와 취향에 따라 결정된다.
지속적인 통합과 전달과 배포 곧 CI/CD 워크플로우는
조직 문화와 취향에 따를 뿐만 아니라
기술적인 요구사항으로 결정된다.
* 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql),
캐시 또는 클러스터 스토리지 시스템(예, Ceph)와 같은 애플리케이션 레벨의 서비스를
제공하지 않는다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서
제공하지 않는다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고,
쿠버네티스 상에서
구동 중인 애플리케이션이 Open Service Broker와 같은 이식 가능한 메커니즘을 통해 접근할
수도 있다.
* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나,
* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다.
개념 증명을 위한 일부 통합이나,
메트릭을 수집하고 노출하는 메커니즘을 제공한다.
* 기본 설정 언어/시스템(예, [jsonnet](https://github.com/google/jsonnet))을 제공하거나
요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
요구하지 않는다.
선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을
제공하거나 채택하지 않는다.
추가로, 쿠버네티스는 단순한 *오케스트레이션 시스템* 이 아니다. 사실,
쿠버네티스는 오케스트레이션의 필요성을 없애준다. *오케스트레이션* 의
기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를
수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어
추가로, 쿠버네티스는 단순한 *오케스트레이션 시스템* 이 아니다.
사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다.
*오케스트레이션* 의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이
정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는
독립적이고 조합 가능한 제어 프로세스들로 구성되어
있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다.
A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이
보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
보다 더 사용하기 쉬워지고,
강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
## 왜 컨테이너인가
@@ -110,41 +128,48 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필
애플리케이션을 배포하는 *옛 방식* 은 운영 체제의 패키지 관리자를
사용해서 애플리케이션을 호스트에 설치하는 것이었다. 이 방식은
애플리케이션의 실행 파일, 설정, 라이브러리 서로 간의 라이프사이클과
호스트 OS와 얽히게 된다는 단점이 있다. 예측 가능한 롤아웃과 롤백을
위해서 불변의 가상 머신 이미지를 만들 수도 있지만, VM은 너무 크고
이식 가능하지 않다.
호스트 OS와 얽히게 된다는 단점이 있다.
예측 가능한 롤아웃과 롤백을
위해서 불변의 가상 머신 이미지를 만들 수도 있지만,
VM은 너무 크고 이식 가능하지 않다.
*새로운 방법* 은 하드웨어 가상화가 아닌 운영 체제 수준의 가상화에 기반한
컨테이너를 배포하는 것이다. 이 컨테이너는 서로 격리되고 호스트와도
격리된다. 컨테이너는 컨테이너 자체의 파일시스템을 갖고, 다른 컨테이너의
프로세스를 알 수 없으며, 연산에 필요한 자원을 제한할 수 있다. VM보다
빌드하기 쉬우며, 기반이 되는 인프라스트럭처와 호스트 파일시스템에서
컨테이너를 배포하는 것이다. 이 컨테이너는 서로 격리되고 호스트와도 격리된다.
컨테이너는 컨테이너 자체의 파일시스템을 갖고,
다른 컨테이너의 프로세스를 알 수 없으며,
연산에 필요한 자원을 제한할 수 있다.
VM보다 빌드하기 쉬우며,
기반이 되는 인프라스트럭처와 호스트 파일시스템에서
디커플되었기(decoupled) 때문에 클라우드나 OS 배포판 간 이식성이 있다.
컨테이너는 작고 빠르기 때문에, 애플리케이션 각각을 컨테이너 이미지로
패키지할 수 있다. 이렇게 애플리케이션과 이미지를 일대일 관계를 갖도록
하면 컨테이너의 혜택을 만끽할 수 있게 된다. 불변의 컨테이너 이미지는
배포 시점이 아닌 빌드/릴리스 시점에 만들어질 수 있다. 왜냐하면 각각의
애플리케이션은 애플리케이션 스택 외의 나머지 요소와 조합될 필요가 없기
때문이고, 운영 인프라스트럭처 환경에 밀접하게 결합시킬 필요도 없기
때문이다. 컨테이너 이미지를 빌드/릴리스 시점에 생성하게 되면 개발
환경부터 운영 환경까지 일관된 환경을 가져갈 수 있게 된다. 마찬가지로,
컨테이너는 VM보다 훨씬 더 투명해서 모니터링과 관리가 용이하다.
패키지할 수 있다. 이렇게 애플리케이션과 이미지를 일대일 관계를 갖도록 하면
컨테이너의 혜택을 만끽할 수 있게 된다.
불변의 컨테이너 이미지는
배포 시점이 아닌 빌드/릴리스 시점에 만들어질 수 있다.
왜냐하면 각각의 애플리케이션은
애플리케이션 스택 외의 나머지 요소와 조합될 필요가 없기 때문이고,
운영 인프라스트럭처 환경에 밀접하게 결합시킬 필요도 없기 때문이다.
컨테이너 이미지를 빌드/릴리스 시점에 생성하게 되면 개발
환경부터 운영 환경까지 일관된 환경을 가져갈 수 있게 된다.
마찬가지로, 컨테이너는 VM보다 훨씬 더 투명해서 모니터링과 관리가 용이하다.
컨테이너의 프로세스 라이프사이클이 수퍼바이저 프로세스에 의해 컨테이너
내에 감추어지지 않고, 인프라스트럭처에 의해 관리될 때 더욱 이는
용이해진다. 컨테이너마다 단일 애플리케이션을 담게되면, 궁극적으로
컨테이너를 관리하는 것이 애플리케이션의 배포를 관리하는 것과 같아진다.
용이해진다. 컨테이너마다 단일 애플리케이션을 담게되면,
궁극적으로 컨테이너를 관리하는 것이 애플리케이션의 배포를 관리하는 것과 같아진다.
컨테이너의 혜택 요약:
* **기민한 애플리케이션 생성과 배포**:
VM 이미지 사용 대비 컨테이너 이미지 생성이 보다 쉽고 효율적임.
* **지속적인 개발, 통합 및 배포**:
안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고
안정적이고 주기적으로 컨테이너 이미지를
빌드해서 배포할 수 있고
(이미지의 불변성 덕에) 빠르고 쉽게 롤백할 수 있다.
* **개발과 운영의 관심사 분리**:
배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를
만들기 때문에, 애플리케이션이 인프라스트럭처에서 디커플된다.
배포 시점이 아닌 빌드/릴리스 시점에
애플리케이션 컨테이너 이미지를 만들기 때문에,
애플리케이션이 인프라스트럭처에서 디커플된다.
* **가시성**
OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와
그 밖의 시그널을 볼 수 있다.
@@ -154,8 +179,7 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필
Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine 및 다른 어디에서든 구동된다.
* **애플리케이션 중심 관리**:
가상 하드웨어의 OS에서 애플리케이션을 구동하는 수준에서 OS의
논리적인 자원을 사용하여 애플리케이션을 구동하는 수준으로 추상화
수준이 높아진다.
논리적인 자원을 사용하여 애플리케이션을 구동하는 수준으로 추상화 수준이 높아진다.
* **느슨하게 커플되고, 분산되고, 유연하며, 자유로운 [마이크로서비스](https://martinfowler.com/articles/microservices.html)**:
애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로
구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고
@@ -165,11 +189,13 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필
* **지원 사용량**:
고효율 고집적.
## 쿠버네티스의 뜻은? K8s?
## 쿠버네티스와 K8s의 뜻
**쿠버네티스**는 *키잡이* 나 *파일럿* 을 뜻하는 그리스어에서 유래했으며,
이는 *governor*(통치자)와 [cybernetic(인공두뇌학)](http://www.etymonline.com/index.php?term=cybernetics)의
어원이다. *K8s* 는 "ubernete" 8 글자를 "8"로 대체한 약어이다.
이는 *governor*(통치자)와
[cybernetic(인공두뇌학)](http://www.etymonline.com/index.php?term=cybernetics)의
어원이다.
*K8s* 는 "ubernete" 8 글자를 "8"로 대체한 약어이다.
{{% /capture %}}
@@ -177,3 +203,5 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필
* [시작할](/docs/setup/) 준비가 되었는가?
* 보다 자세한 내용은 [쿠버네티스 문서](/ko/docs/home/)를 참조한다.
{{% /capture %}}
content/ko/docs/concepts/overview/working-with-objects/namespaces.md
+25 -23
View File
@@ -17,24 +17,26 @@ weight: 30
## 복수의 네임스페이스를 사용하는 경우
네임스페이스는 복수의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록
만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는, 네임스페이스를 고려할
필요가 전혀 없다. 네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자.
만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는,
네임스페이스를 고려할 필요가 전혀 없다.
네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자.
네임스페이스는 이름의 범위를 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야하지만, 네임스페이스를 통틀어서 유일할 필요는 없다.
네임스페이스는 이름의 범위를 제공한다.
리소스의 이름은 네임스페이스 내에서 유일해야하지만,
네임스페이스를 통틀어서 유일할 필요는 없다.
네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다.
다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근
제어 정책을 갖게 된다. 네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스
리소스는 하나의 네임스페이스에만 있을 수 있다.
다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근 제어 정책을 갖게 된다.
네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다.
같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서
복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를
같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서
복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를
구분하기 위해서는 [레이블](/docs/user-guide/labels)을 사용한다.
## 네임스페이스 다루기
네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/admin/namespace)에
네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/admin/namespace)에
기술되어 있다.
### 네임스페이스 조회
@@ -42,7 +44,7 @@ weight: 30
사용중인 클러스터의 현재 네임스페이스를 나열할 수 있다.
```shell
kubectl get namespaces
kubectl get namespace
```
```
NAME STATUS AGE
@@ -64,33 +66,33 @@ kube-public Active 1d
예를 들면,
```shell
$ kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
$ kubectl --namespace=<insert-namespace-name-here> get pods
kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
kubectl --namespace=<insert-namespace-name-here> get pods
```
### 선호하는 네임스페이스 설정하기
이후 모든 kubectl 명령에서 사용될 네임스페이스를 컨텍스트에 영구적으로 저장할 수 있다.
이후 모든 kubectl 명령에서 사용될 네임스페이스를 컨텍스트에
영구적으로 저장할 수 있다.
```shell
$ kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
# 확인하기
$ kubectl config view | grep namespace:
kubectl config view | grep namespace:
```
## 네임스페이스와 DNS
[서비스](/docs/user-guide/services)를 생성하면, 대응되는
[서비스](/docs/user-guide/services)를 생성하면, 대응되는
[DNS 엔트리](/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데,
이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로
연결된다. 개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을
사용하는 경우에 유용하다. 네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인
이름(FQDN)을 사용해야 한다.
이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.
개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다.
네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인 이름(FQDN)을 사용해야 한다.
## 모든 오브젝트가 네임스페이스에 속하지는 않음
대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는
대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는
네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다.
그리고 [nodes](/docs/admin/node)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
네임스페이스에도 속하지 않는다.
@@ -99,10 +101,10 @@ $ kubectl config view | grep namespace:
```shell
# 네임스페이스에 속하는 리소스
$ kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=true
# 네임스페이스에 속하지 않는 리소스
$ kubectl api-resources --namespaced=false
kubectl api-resources --namespaced=false
```
{{% /capture %}}