Seventh Korean l10n Work For Release 1.17 (#19857)
- Translation error correction with k8s.io/ko/docs/concepts/overview/components.md (#19720) - Error correction with overview/working-with-objects/kubernetes-objects.md (#19735) - Fix issues with working-with-objects/namespaces.md (#19753) - Issue with working-with-objects/object-management.md (#19740) - Fix issue with working-with-objects/labels.md (#19763) - Translate training/_index.html in Korean. (#19718) - Update links to docs that reference new docs added in the dev-1.17-ko.6 branch. (#19724) - Fix Issues with working-with-objects/names.md (#19749) - Update to Outdated files in the dev-1.17-ko.7 branch (#19712) - Error correction with /concepts/overview/kubernetes-api.md (#19733) - Translation error correction in /concepts/overview/what-is-kubernetes.md (#19710) - Typo in /contribute/participating.md (#19683) - Correct the Korean word typo 맴버 to 멤버 (#19674) Co-Authored-by: Jerry Park <jaehwa@gmail.com> Co-Authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-by: June Yi <june.yi@samsung.com> Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>pull/19999/head
Claudia J.Kang
bryan
parent
8b983433c9
commit
663192c5b6
|
|
@ -45,12 +45,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020</a>
|
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon in Amsterdam in July/August TBD</a>
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
<a href="https://www.lfasiallc.cn/kubecon-cloudnativecon-open-source-summit-china/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncch20" button id="desktopKCButton">Attend KubeCon in Shanghai on July 28-30, 2020</a>
|
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Attend KubeCon in Boston on November 17-20, 2020</a>
|
||||||
</div>
|
</div>
|
||||||
<div id="videoPlayer">
|
<div id="videoPlayer">
|
||||||
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
|
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
|
||||||
|
|
|
||||||
|
|
@ -41,7 +41,7 @@ weight: 40
|
||||||
* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)
|
* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)
|
||||||
* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/)
|
* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/)
|
||||||
* [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)
|
* [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)
|
||||||
* [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
* [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
||||||
|
|
||||||
## 쿠버네티스 컨트롤 플레인
|
## 쿠버네티스 컨트롤 플레인
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -74,7 +74,7 @@ apiserver는 kubelet의 제공 인증서를 확인하지 않는데,
|
||||||
플래그를 이용한다
|
플래그를 이용한다
|
||||||
|
|
||||||
그것이 불가능한 경우, 신뢰할 수 없는 또는 공인 네트워크에 대한 연결을 피하고 싶다면,
|
그것이 불가능한 경우, 신뢰할 수 없는 또는 공인 네트워크에 대한 연결을 피하고 싶다면,
|
||||||
apiserver와 kubelet 사이에 [SSH 터널링](/docs/concepts/architecture/master-node-communication/#ssh-터널)을
|
apiserver와 kubelet 사이에 [SSH 터널링](/ko/docs/concepts/architecture/master-node-communication/#ssh-터널)을
|
||||||
사용한다.
|
사용한다.
|
||||||
|
|
||||||
마지막으로, kubelet API를 안전하게 하기 위해
|
마지막으로, kubelet API를 안전하게 하기 위해
|
||||||
|
|
|
||||||
|
|
@ -128,6 +128,7 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
|
||||||
`metadata.name` 필드를 근거로 상태 체크를 수행하여 노드의 유효성을 확인한다. 노드가 유효하면, 즉
|
`metadata.name` 필드를 근거로 상태 체크를 수행하여 노드의 유효성을 확인한다. 노드가 유효하면, 즉
|
||||||
모든 필요한 서비스가 동작 중이면, 파드를 동작시킬 자격이 된다. 그렇지 않으면,
|
모든 필요한 서비스가 동작 중이면, 파드를 동작시킬 자격이 된다. 그렇지 않으면,
|
||||||
유효하게 될때까지 어떠한 클러스터 활동에 대해서도 무시된다.
|
유효하게 될때까지 어떠한 클러스터 활동에 대해서도 무시된다.
|
||||||
|
노드 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
|
||||||
|
|
||||||
{{< note >}}
|
{{< note >}}
|
||||||
쿠버네티스는 유효하지 않은 노드로부터 오브젝트를 보호하고 유효한 상태로 이르는지 확인하기 위해 지속적으로 체크한다.
|
쿠버네티스는 유효하지 않은 노드로부터 오브젝트를 보호하고 유효한 상태로 이르는지 확인하기 위해 지속적으로 체크한다.
|
||||||
|
|
|
||||||
|
|
@ -31,7 +31,7 @@ weight: 10
|
||||||
|
|
||||||
## 클러스터 관리
|
## 클러스터 관리
|
||||||
|
|
||||||
* [클러스터 관리](/docs/tasks/administer-cluster/cluster-management/)는 클러스터의 라이프사이클과 관련된 몇 가지 주제를 설명한다. 이는 새 클러스터 생성, 마스터와 워커노드 업그레이드, 노드 유지보수 실행 (예: 커널 업그레이드), 그리고 동작 중인 클러스터의 쿠버네티스 API 버전 업그레이드 등을 포함한다.
|
* [클러스터 관리](/ko/docs/tasks/administer-cluster/cluster-management/)는 클러스터의 라이프사이클과 관련된 몇 가지 주제를 설명한다. 이는 새 클러스터 생성, 마스터와 워커노드 업그레이드, 노드 유지보수 실행 (예: 커널 업그레이드), 그리고 동작 중인 클러스터의 쿠버네티스 API 버전 업그레이드 등을 포함한다.
|
||||||
|
|
||||||
* 어떻게 [노드 관리](/ko/docs/concepts/architecture/nodes/)를 하는지 배워보자.
|
* 어떻게 [노드 관리](/ko/docs/concepts/architecture/nodes/)를 하는지 배워보자.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,186 +0,0 @@
|
||||||
---
|
|
||||||
title: 페더레이션
|
|
||||||
content_template: templates/concept
|
|
||||||
weight: 80
|
|
||||||
---
|
|
||||||
|
|
||||||
{{% capture overview %}}
|
|
||||||
|
|
||||||
{{< deprecationfilewarning >}}
|
|
||||||
{{< include "federation-deprecation-warning-note.md" >}}
|
|
||||||
{{< /deprecationfilewarning >}}
|
|
||||||
|
|
||||||
이 페이지는 여러 쿠버네티스 클러스터를 페더레이션을 통해서 관리해야 하는 이유와 방법을
|
|
||||||
설명한다.
|
|
||||||
{{% /capture %}}
|
|
||||||
|
|
||||||
{{% capture body %}}
|
|
||||||
## 페더레이션 이유
|
|
||||||
|
|
||||||
페더레이션을 사용하면 여러 클러스터를 쉽게 관리할 수 있다. 이는 2가지 주요 빌딩 블록을
|
|
||||||
제공함으로써 이루어진다.
|
|
||||||
|
|
||||||
* 클러스터 간의 리소스 동기화: 페더레이션은 여러 클러스터 내의 리소스를
|
|
||||||
동기화하는 능력을 제공한다. 예를 들면, 여러 클러스터에 동일한 디플로이먼트가 존재하는 것을 확인 할 수 있다.
|
|
||||||
* 클러스터 간의 디스커버리: 페더레이션은 모든 클러스터의 백엔드에 DNS 서버 및 로드벨런서를 자동 구성하는 능력을 제공한다. 예를 들면, 글로벌 VIP 또는 DNS 기록이 여러 클러스터의 백엔드 엑세스에 사용될 수 있는 것을 확인할 수 있다.
|
|
||||||
|
|
||||||
페더레이션이 가능하게 하는 다른 사례는 다음과 같다.
|
|
||||||
|
|
||||||
* 고가용성: 클러스터에 걸쳐서 부하를 분산하고 DNS
|
|
||||||
서버와 로드벨런서를 자동 구성함으로써, 페더레이션은 클러스터 장애의 영향을
|
|
||||||
최소화한다.
|
|
||||||
* 공급자 락인(lock-in) 회피: 애플리케이션의 클러스터 간 마이그레이션을 쉽게
|
|
||||||
만듦으로써, 페더레이션은 클러스터 공급자의 락인을 방지한다.
|
|
||||||
|
|
||||||
|
|
||||||
여러 클러스터를 운영하는 경우가 아니면 페더레이션은 필요 없다. 여러 클러스터가 필요한
|
|
||||||
이유의 일부는 다음과 같다.
|
|
||||||
|
|
||||||
* 짧은 지연시간: 클러스터가 여러 지역(region)에 있으면 사용자에게 가장 가까운 클러스터로부터
|
|
||||||
서비스함으로써 지연시간을 최소화한다.
|
|
||||||
* 결함 격리: 하나의 큰 클러스터보다 여러 개의 작은 클러스터를 사용하는 것이
|
|
||||||
결함을 격리하는데 더 효과적이다(예를 들면, 클라우드
|
|
||||||
공급자의 다른 가용 영역(availability zone)에 있는 여러 클러스터).
|
|
||||||
* 확장성: 단일 쿠버네티스 클러스터는 확장성에 한계가 있다(일반적인
|
|
||||||
사용자에게 해당되는 사항은 아니다. 더 자세한 내용:
|
|
||||||
[쿠버네티스 스케일링 및 성능 목표](https://git.k8s.io/community/sig-scalability/goals.md)).
|
|
||||||
* [하이브리드 클라우드](#하이브리드-클라우드-역량): 다른 클라우드 공급자나 온-프레미스 데이터 센터에 있는 여러 클러스터를
|
|
||||||
운영할 수 있다.
|
|
||||||
|
|
||||||
### 주의 사항
|
|
||||||
|
|
||||||
페더레이션에는 매력적인 사례가 많지만, 다소 주의 해야 할
|
|
||||||
사항도 있다.
|
|
||||||
|
|
||||||
* 네트워크 대역폭과 비용 증가: 페더레이션 컨트롤 플레인은 모든 클러스터를
|
|
||||||
감시하여 현재 상태가 예정된 상태와 같은지 확인한다. 이것은 클러스터들이
|
|
||||||
한 클라우드 제공자의 여러 다른 지역에서 또는 클라우드 제공자 간에 걸쳐 동작하는
|
|
||||||
경우 상당한 네트워크 비용을 초래할 수 있다.
|
|
||||||
* 클러스터 간 격리 수준 감소: 페더레이션 컨트롤 플레인에서의 오류는 모든 클러스터에
|
|
||||||
영향을 줄 수 있다. 이것은 페더레이션 컨트롤 플레인의 논리를 최소한으로
|
|
||||||
유지함으로써 완화된다. 페더레이션은 가능한 경우 언제라도
|
|
||||||
쿠버네티스 클러스터에 컨트롤 플레인을 위임한다. 페더레이션은 안전성을 제공하고
|
|
||||||
여러 클러스터의 중단을 방지할 수 있도록 민감하게 설계 및 구현되었다.
|
|
||||||
* 성숙도: 페더레이션 프로젝트는 상대적으로 신규 프로젝트이고 성숙도가 높지 않다.
|
|
||||||
모든 리소스가 이용 가능한 상태는 아니며 많은 리소스가 아직 알파 상태이다. [이슈
|
|
||||||
88](https://github.com/kubernetes/federation/issues/88)은 팀이 해결
|
|
||||||
중에 있는 시스템의 알려진 이슈를 열거하고 있다.
|
|
||||||
|
|
||||||
### 하이브리드 클라우드 역량
|
|
||||||
|
|
||||||
쿠버네티스 클러스터의 페더레이션은 다른 클라우드 제공자(예를 들어, Google 클라우드, AWS),
|
|
||||||
그리고 온-프레미스(예를 들어, OpenStack)에서 동작 중인 클러스터를 포함할 수
|
|
||||||
있다. [Kubefed](/docs/tasks/federation/set-up-cluster-federation-kubefed/)는 연합된 클러스터 배치에 권장되는 방법이다.
|
|
||||||
|
|
||||||
그 후에, [API 리소스](#api-리소스)는 서로 다른 클러스터와 클라우드
|
|
||||||
제공자에 걸쳐 확장될 수 있다.
|
|
||||||
|
|
||||||
## 페더레이션 설치
|
|
||||||
|
|
||||||
여러 클러스터의 페더레이션 구성을 위해서는, 페더레이션 컨트롤 플레인을 우선적으로
|
|
||||||
설치해야 한다.
|
|
||||||
페더레이션 컨트롤 플레인의 설치를 위해서는 [설치 가이드](/docs/tutorials/federation/set-up-cluster-federation-kubefed/)
|
|
||||||
를 따른다.
|
|
||||||
|
|
||||||
## API 리소스
|
|
||||||
|
|
||||||
컨트롤 플레인이 설치되고 나면, 페더레이션 API 리소스 생성을 시작할 수
|
|
||||||
있다.
|
|
||||||
다음의 가이드는 일부 리소스에 대해서 자세히 설명한다.
|
|
||||||
|
|
||||||
* [클러스터](/docs/tasks/federation/administer-federation/cluster/)
|
|
||||||
* [컨피그 맵](/docs/tasks/federation/administer-federation/configmap/)
|
|
||||||
* [데몬 셋](/docs/tasks/federation/administer-federation/daemonset/)
|
|
||||||
* [디플로이먼트](/docs/tasks/federation/administer-federation/deployment/)
|
|
||||||
* [이벤트](/docs/tasks/federation/administer-federation/events/)
|
|
||||||
* [Hpa](/docs/tasks/federation/administer-federation/hpa/)
|
|
||||||
* [인그레스](/docs/tasks/federation/administer-federation/ingress/)
|
|
||||||
* [잡](/docs/tasks/federation/administer-federation/job/)
|
|
||||||
* [네임스페이스](/docs/tasks/federation/administer-federation/namespaces/)
|
|
||||||
* [레플리카 셋](/docs/tasks/federation/administer-federation/replicaset/)
|
|
||||||
* [시크릿](/docs/tasks/federation/administer-federation/secret/)
|
|
||||||
* [서비스](/docs/concepts/cluster-administration/federation-service-discovery/)
|
|
||||||
|
|
||||||
|
|
||||||
[API 참조 문서](/docs/reference/federation/)는 페더레이션
|
|
||||||
apiserver가 지원하는 모든 리소스를 열거한다.
|
|
||||||
|
|
||||||
## 삭제 캐스케이딩(cascading)
|
|
||||||
|
|
||||||
쿠버네티스 버전 1.6은 연합된 리소스에 대한 삭제 캐스케이딩을
|
|
||||||
지원한다. 삭제 케스케이딩이 적용된 경우, 페더레이션 컨트롤 플레인에서
|
|
||||||
리소스를 삭제하면, 모든 클러스터에서 상응하는 리소스가 삭제된다.
|
|
||||||
|
|
||||||
REST API 사용하는 경우 삭제 캐스케이딩이 기본으로 활성화되지 않는다. 그것을
|
|
||||||
활성화하려면, REST API를 사용하여 페더레이션 컨트롤 플레인에서 리소스를 삭제할 때
|
|
||||||
`DeleteOptions.orphanDependents=false` 옵션을 설정한다. `kubectl
|
|
||||||
delete`를 사용하면
|
|
||||||
삭제 캐스케이딩이 기본으로 활성화된다. `kubectl
|
|
||||||
delete --cascade=false`를 실행하여 비활성화할 수 있다.
|
|
||||||
|
|
||||||
참고: 쿠버네티스 버전 1.5는 페더레이션 리소스의 부분 집합에 대한 삭제
|
|
||||||
캐스케이딩을 지원하였다.
|
|
||||||
|
|
||||||
## 단일 클러스터의 범위
|
|
||||||
|
|
||||||
Google Compute Engine 또는 Amazon Web Services와 같은 IaaS 제공자에서는, VM이
|
|
||||||
[영역(zone)](https://cloud.google.com/compute/docs/zones) 또는 [가용 영역(availability
|
|
||||||
zone)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)에 존재한다.
|
|
||||||
다음과 같은 이유로, 쿠버네티스 클러스터의 모든 VM을 동일한 가용 영역에 두는 것을 추천한다.
|
|
||||||
|
|
||||||
- 단일 글로벌 쿠버네티스 클러스터에 비해서, 장애에 대한 단일-포인트가 더 적다.
|
|
||||||
- 여러 가용 영역에 걸친 클러스터에 비해서, 단일-영역 클러스터의 가용성 속성에 대한 추론이
|
|
||||||
더 쉽다.
|
|
||||||
- 쿠버네티스 개발자가 시스템을 디자인할 때(예를 들어, 지연 시간, 대역폭, 연관된 장애를
|
|
||||||
고려할 때) 모든 기계가 단일 데이터 센터에 있거나 밀접하게 연결되어 있다고 가정하고 있다.
|
|
||||||
|
|
||||||
가용 영역당 더 많은 VM이 포함되는 적은 수의 클러스터 실행을 추천한다. 다만, 여러 가용 영역 마다 여러 클러스터의 실행도 가능하다.
|
|
||||||
|
|
||||||
가용 영역당 더 적은 수의 클러스터가 선호되는 이유는 다음과 같다.
|
|
||||||
|
|
||||||
- 한 클러스터에 많은 노드가 있는 일부의 경우 파드의 빈 패킹(bin packing)이 향상됨(리소스 단편화 감소).
|
|
||||||
- 운영 오버헤드 감소(운영 툴과 프로세스의 성숙도에 의해 해당 장점은 반감되는 측면이 있음).
|
|
||||||
- apiserver VMs와 같이, 클러스터당 비용이 고정된 리소스의 비용을 감소(그러나 중간 규모 부터 큰 규모에 이르는 클러스터의
|
|
||||||
전체 클러스터 비용에 비하면 상대적으로 적은 비용).
|
|
||||||
|
|
||||||
여러 클러스터가 필요한 이유는 다음을 포함한다.
|
|
||||||
|
|
||||||
- 다른 업무의 계층으로부터 특정 계층의 격리가 요구되는 엄격한 보안 정책(다만, 아래의 클러스터 분할하기 정보를 확인하기
|
|
||||||
바람).
|
|
||||||
- 새로운 쿠버네티스 릴리스 또는 다른 클러스터 소프트웨어를 카나리아(canary) 방식으로 릴리스하기 위해서 클러스터를 테스트.
|
|
||||||
|
|
||||||
## 적절한 클러스터 수 선택하기
|
|
||||||
|
|
||||||
쿠버네티스 클러스터의 수를 선택하는 것은 상대적으로 고정적인 선택이며, 가끔식만 재고된다.
|
|
||||||
대조적으로, 클러스터의 노드 수와 서비스 내의 파드 수는 부하와 규모 증가에 따라
|
|
||||||
빈번하게 변경될 수 있다.
|
|
||||||
|
|
||||||
클러스터의 수를 선택하기 위해서, 첫 번째로, 쿠버네티스에서 동작할 서비스의 모든 최종 사용자에게 적절한 지연 시간을 제공할 수 있는 지역들을 선택할
|
|
||||||
필요가 있다(만약 콘텐츠 전송 네트워크를 사용한다면, CDN-호스트된 콘텐츠의 지연 시간 요구사항
|
|
||||||
고려할 필요가 없음). 법적인 이슈 또한 이것에 영향을 줄 수 있다. 예를 들면, 어떤 글로벌 고객 기반의 회사는 US, AP, SA 지역 등 특정 지역에서 클러스터를 운영하도록 결정할 수도 있다.
|
|
||||||
지역의 수를 `R`이라 부르자.
|
|
||||||
|
|
||||||
두 번째로, 여전히 사용 가능한 상태에서, 얼마나 많은 클러스터가 동시에 사용할 수 없는 상태가 될 수 있는지 결정한다.
|
|
||||||
사용하지 않는 상태가 될 수 있는 수를 `U`라고 하자. 만약이 값에 확신이 없다면, 1이 괜찮은 선택이다.
|
|
||||||
|
|
||||||
클러스터 장애 상황에서 어느 지역으로든지 직접적인 트래픽에 대한 로드밸런싱이 허용된다면, `R`
|
|
||||||
또는 적어도 `U + 1` 이상의 클러스터가 있으면 된다. 만약 그렇지 않다면(예를 들어, 클러스터 장애 상황에서 모든
|
|
||||||
사용자에 대한 낮은 지연 시간을 유지하고 싶다면), `R * (U + 1)`(각 `R` 지역 내에 `U + 1`)
|
|
||||||
클러스터가 필요하다. 어느 경우든지, 각 클러스터는 다른 영역에 배치하도록 노력하는 것이 좋다.
|
|
||||||
|
|
||||||
마지막으로, 클러스터 중 어느 클러스터라도 쿠버네티스 클러스터에서 추천되는 최대 노드 수 보다 더 많은 노드가 필요하다면,
|
|
||||||
더 많은 클러스터가 필요할 것이다. 쿠버네티스 v1.3은 클러스터를 최대 1000노드까지 지원한다. 쿠버네티스 v1.8은
|
|
||||||
클러스터를 최대 5000 노드까지 지원한다. 더 자세한 가이드는 [대규모 클러스터 구축하기](/docs/setup/best-practices/cluster-large/)에서 확인 가능하다.
|
|
||||||
|
|
||||||
{{% /capture %}}
|
|
||||||
|
|
||||||
{{% capture whatsnext %}}
|
|
||||||
* [페더레이션
|
|
||||||
제안](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)에 대해 더 학습하기.
|
|
||||||
* 클러스터 페더레이션 [설치 가이드](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) 보기.
|
|
||||||
* [Kubecon2016 페더레이션 발표](https://www.youtube.com/watch?v=pq9lbkmxpS8) 보기
|
|
||||||
* [Kubecon2017 유럽 페더레이션 업데이트 내용](https://www.youtube.com/watch?v=kwOvOLnFYck) 보기
|
|
||||||
* [Kubecon2018 유럽 sig-multicluster 업데이트 내용](https://www.youtube.com/watch?v=vGZo5DaThQU) 보기
|
|
||||||
* [Kubecon2018 유럽 Federation-v2 프로토타입 발표](https://youtu.be/q27rbaX5Jis?t=7m20s) 보기
|
|
||||||
* [Federation-v2 사용자 가이드](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md) 보기
|
|
||||||
{{% /capture %}}
|
|
||||||
|
|
@ -14,7 +14,7 @@ weight: 90
|
||||||
|
|
||||||
쿠버네티스를 이용할 때에 사용할 수 있는 여러 프락시가 있다.
|
쿠버네티스를 이용할 때에 사용할 수 있는 여러 프락시가 있다.
|
||||||
|
|
||||||
1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
|
1. [kubectl proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#rest-api에-직접-액세스):
|
||||||
|
|
||||||
- 사용자의 데스크탑이나 파드 안에서 실행한다.
|
- 사용자의 데스크탑이나 파드 안에서 실행한다.
|
||||||
- 로컬 호스트 주소에서 쿠버네티스의 API 서버로 프락시한다.
|
- 로컬 호스트 주소에서 쿠버네티스의 API 서버로 프락시한다.
|
||||||
|
|
@ -23,7 +23,7 @@ weight: 90
|
||||||
- API 서버를 찾는다.
|
- API 서버를 찾는다.
|
||||||
- 인증 헤더를 추가한다.
|
- 인증 헤더를 추가한다.
|
||||||
|
|
||||||
1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
|
1. [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#빌트인-서비스들의-발견):
|
||||||
|
|
||||||
- API 서버에 내장된 요새(bastion)이다.
|
- API 서버에 내장된 요새(bastion)이다.
|
||||||
- 클러스터 외부의 사용자가 도달할 수 없는 클러스터 IP 주소로 연결한다.
|
- 클러스터 외부의 사용자가 도달할 수 없는 클러스터 IP 주소로 연결한다.
|
||||||
|
|
|
||||||
|
|
@ -107,7 +107,8 @@ spec:
|
||||||
`nodeSelector` 는 파드를 특정 레이블이 있는 노드로 제한하는 매우 간단한 방법을 제공한다.
|
`nodeSelector` 는 파드를 특정 레이블이 있는 노드로 제한하는 매우 간단한 방법을 제공한다.
|
||||||
어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다. 주요 개선 사항은 다음과 같다.
|
어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다. 주요 개선 사항은 다음과 같다.
|
||||||
|
|
||||||
1. 언어가 보다 표현적이다("AND 또는 정확한 일치" 만이 아니다).
|
1. 어피니티/안티-어피니티 언어가 더 표현적이다. 언어는 논리 연산자인 AND 연산으로 작성된
|
||||||
|
정확한 매칭 항목 이외에 더 많은 매칭 규칙을 제공한다.
|
||||||
2. 규칙이 엄격한 요구 사항이 아니라 "유연한(soft)"/"선호(preference)" 규칙을 나타낼 수 있기에 스케줄러가 규칙을 만족할 수 없더라도,
|
2. 규칙이 엄격한 요구 사항이 아니라 "유연한(soft)"/"선호(preference)" 규칙을 나타낼 수 있기에 스케줄러가 규칙을 만족할 수 없더라도,
|
||||||
파드가 계속 스케줄 되도록 한다.
|
파드가 계속 스케줄 되도록 한다.
|
||||||
3. 노드 자체에 레이블을 붙이기보다는 노드(또는 다른 토폴로지 도메인)에서 실행 중인 다른 파드의 레이블을 제한할 수 있다.
|
3. 노드 자체에 레이블을 붙이기보다는 노드(또는 다른 토폴로지 도메인)에서 실행 중인 다른 파드의 레이블을 제한할 수 있다.
|
||||||
|
|
@ -155,9 +156,9 @@ spec:
|
||||||
`nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄 되기 위해서는
|
`nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄 되기 위해서는
|
||||||
*둘 다* 반드시 만족해야 한다.
|
*둘 다* 반드시 만족해야 한다.
|
||||||
|
|
||||||
`nodeAffinity` 유형과 연관된 `nodeSelectorTerms` 를 지정하면, 파드를 `nodeSelectorTerms` 가 지정된 것 중 **한 가지**라도 만족하는 노드에 스케줄할 수 있다.
|
`nodeAffinity` 유형과 연관된 `nodeSelectorTerms` 를 지정하면, 파드는 `nodeSelectorTerms` 를 **모두** 만족하는 노드에만 스케줄할 수 있다.
|
||||||
|
|
||||||
`nodeSelectorTerms` 와 연관된 여러 `matchExpressions` 를 지정하면, 파드는 `matchExpressions` 를 **모두** 만족하는 노드에만 스케줄할 수 있다.
|
`nodeSelectorTerms` 와 연관된 여러 `matchExpressions` 를 지정하면, 파드는 `matchExpressions` 이 지정된 것 중 **한 가지**라도 만족하는 노드에만 스케줄할 수 있다.
|
||||||
|
|
||||||
파드가 스케줄 된 노드의 레이블을 지우거나 변경해도 파드는 제거되지 않는다. 다시 말해서 어피니티 선택은 파드를 스케줄링 하는 시점에만 작동한다.
|
파드가 스케줄 된 노드의 레이블을 지우거나 변경해도 파드는 제거되지 않는다. 다시 말해서 어피니티 선택은 파드를 스케줄링 하는 시점에만 작동한다.
|
||||||
|
|
||||||
|
|
@ -224,7 +225,7 @@ spec:
|
||||||
1. 어피니티와 `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 대해
|
1. 어피니티와 `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 대해
|
||||||
`topologyKey` 가 비어있는 것을 허용하지 않는다.
|
`topologyKey` 가 비어있는 것을 허용하지 않는다.
|
||||||
2. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를에 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 간단히 이를 비활성화 할 수 있다.
|
2. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를에 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 간단히 이를 비활성화 할 수 있다.
|
||||||
3. `preferredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티의 경우 빈 `topologyKey` 는 "all topology"("all topology"는 현재 `kubernetes.io/hostname`, `failure-domain.beta.kubernetes.io/zone` 그리고 `failure-domain.beta.kubernetes.io/region` 의 조합으로 제한된다)로 해석한다.
|
3. `preferredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 `topologyKey` 가 비어있는 것을 허용하지 않는다.
|
||||||
4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다.
|
4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다.
|
||||||
|
|
||||||
`labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를
|
`labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를
|
||||||
|
|
@ -345,7 +346,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3
|
||||||
위의 예시에서 `topologyKey:"kubernetes.io/hostname"` 과 함께 `PodAntiAffinity` 규칙을 사용해서
|
위의 예시에서 `topologyKey:"kubernetes.io/hostname"` 과 함께 `PodAntiAffinity` 규칙을 사용해서
|
||||||
두 개의 인스터스가 동일한 호스트에 있지 않도록 redis 클러스터를 배포한다.
|
두 개의 인스터스가 동일한 호스트에 있지 않도록 redis 클러스터를 배포한다.
|
||||||
같은 기술을 사용해서 고 가용성을 위해 안티-어피니티로 구성된 스테이트풀셋의 예시는
|
같은 기술을 사용해서 고 가용성을 위해 안티-어피니티로 구성된 스테이트풀셋의 예시는
|
||||||
[ZooKeeper 튜토리얼](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)을 본다.
|
[ZooKeeper 튜토리얼](/ko/docs/tutorials/stateful-application/zookeeper/#노드-실패-방지)을 본다.
|
||||||
|
|
||||||
## nodeName
|
## nodeName
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -23,7 +23,7 @@ kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스
|
||||||
다른 kubeconfig 파일을 사용할 수 있다.
|
다른 kubeconfig 파일을 사용할 수 있다.
|
||||||
|
|
||||||
kubeconfig 파일을 생성하고 지정하는 단계별 지시사항은
|
kubeconfig 파일을 생성하고 지정하는 단계별 지시사항은
|
||||||
[다중 클러스터로 접근 구성하기](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)를 참조한다.
|
[다중 클러스터로 접근 구성하기](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참조한다.
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
@ -97,7 +97,7 @@ kubectl config view
|
||||||
두 번째 파일의 `red-user` 하위에 충돌하지 않는 항목이 있어도 버린다.
|
두 번째 파일의 `red-user` 하위에 충돌하지 않는 항목이 있어도 버린다.
|
||||||
|
|
||||||
`KUBECONFIG` 환경 변수 설정의 예로,
|
`KUBECONFIG` 환경 변수 설정의 예로,
|
||||||
[KUBECONFIG 환경 변수 설정](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)를 참조한다.
|
[KUBECONFIG 환경 변수 설정](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#kubeconfig-환경-변수-설정)를 참조한다.
|
||||||
|
|
||||||
그렇지 않다면, 병합하지 않고 기본 kubecofig 파일인 `$HOME/.kube/config`를 사용한다.
|
그렇지 않다면, 병합하지 않고 기본 kubecofig 파일인 `$HOME/.kube/config`를 사용한다.
|
||||||
|
|
||||||
|
|
@ -148,7 +148,7 @@ kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치
|
||||||
|
|
||||||
{{% capture whatsnext %}}
|
{{% capture whatsnext %}}
|
||||||
|
|
||||||
* [다중 클러스터 접근 구성하기](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
* [다중 클러스터 접근 구성하기](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||||
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
|
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
|
||||||
|
|
@ -32,7 +32,7 @@ weight: 10
|
||||||
|
|
||||||
- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
|
- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
|
||||||
|
|
||||||
명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
|
명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
|
||||||
|
|
||||||
|
|
||||||
## 서비스
|
## 서비스
|
||||||
|
|
|
||||||
|
|
@ -79,6 +79,9 @@ metadata:
|
||||||
handler: myconfiguration # 상응하는 CRI 설정의 이름임
|
handler: myconfiguration # 상응하는 CRI 설정의 이름임
|
||||||
```
|
```
|
||||||
|
|
||||||
|
런타임 클래스 오브젝트의 이름은 유효한
|
||||||
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)어이야 한다.
|
||||||
|
|
||||||
{{< note >}}
|
{{< note >}}
|
||||||
런타임 클래스 쓰기 작업(create/update/patch/delete)은
|
런타임 클래스 쓰기 작업(create/update/patch/delete)은
|
||||||
클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다.
|
클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다.
|
||||||
|
|
|
||||||
|
|
@ -7,24 +7,28 @@ weight: 10
|
||||||
{{% capture overview %}}
|
{{% capture overview %}}
|
||||||
|
|
||||||
애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다.
|
애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다.
|
||||||
|
추가 API는 [서비스-카탈로그](/docs/concepts/extend-kubernetes/service-catalog/)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다.
|
||||||
|
|
||||||
|
애그리게이션 레이어는 [사용자 정의 리소스](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르며, 애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 가 새로운 종류의 오브젝트를 인식하도록 하는 방법이다.
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
{{% capture body %}}
|
{{% capture body %}}
|
||||||
|
|
||||||
## 개요
|
## 애그리게이션 레이어
|
||||||
|
|
||||||
애그리게이션 레이어는 부가적인 쿠버네티스-스타일 API를 클러스터에 설치할 수 있게 해준다. 이는 [서비스-카탈로그](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)와 같이 사전에 구축되어 있는 서드 파티 솔루션일 수 있고, [apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)로 시작해볼 수 있는 것과 같은 사용자 정의 API일 수도 있다.
|
|
||||||
|
|
||||||
애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지, 애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를 "요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는 해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다.
|
애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지, 애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를 "요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는 해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다.
|
||||||
|
|
||||||
대개, APIService는 클러스터 내에서 구동 중인 파드(pod) 내 *extension-apiserver* 로 구현된다. 이 extension-apiserver는 일반적으로 추가된 리소스에 대한 적극적인 관리가 필요한 경우 하나 이상의 컨트롤러와 짝지어진다. 결과적으로, apiserver-builder는 실제로 그 둘 모두에 대한 스켈레톤을 제공한다. 또 다른 예로, 서비스-카탈로그가 설치된 경우에는, 제공하는 서비스에 대한 extension-apiserver와 컨트롤러를 모두 제공한다.
|
APIService를 구현하는 가장 일반적인 방법은 클러스터 내에 실행되고 있는 파드에서 *extension API server* 를 실행하는 것이다. extension API server를 사용해서 클러스터의 리소스를 관리하는 경우 extension API server("extension-apiserver" 라고도 한다)는 일반적으로 하나 이상의 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}와 쌍을 이룬다. apiserver-builder 라이브러리는 extension API server와 연관된 컨틀로러에 대한 스켈레톤을 제공한다.
|
||||||
|
|
||||||
|
### 응답 레이턴시
|
||||||
|
|
||||||
Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮아야 한다.
|
Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮아야 한다.
|
||||||
특히, kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다.
|
kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다.
|
||||||
사용자의 환경에서 달성할 수 없는 경우에는, 이를 어떻게 바꿀 수 있을지 고려해야 한다. 지금은,
|
|
||||||
`EnableAggregatedDiscoveryTimeout=false` 기능 게이트를 설정해서 타임아웃 제한을
|
extention API server가 레이턴시 요구 사항을 달성할 수 없는 경우 이를 충족할 수 있도록 변경하는 것을 고려한다.
|
||||||
비활성화 할 수 있다. 이 기능은 미래의 릴리스에서는 삭제될 예정이다.
|
`EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃
|
||||||
|
제한을 비활성화 할 수 있다. 이 사용 중단(deprecated)된 기능 게이트는 향후 릴리스에서 제거될 예정이다.
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
@ -33,6 +37,6 @@ Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮
|
||||||
* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
|
* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
|
||||||
* 다음에, [extension api-server를 구성해서](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
|
* 다음에, [extension api-server를 구성해서](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
|
||||||
* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)를 배워본다.
|
* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)를 배워본다.
|
||||||
|
* [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다.
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -21,12 +21,12 @@ card:
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
{{% capture body %}}
|
{{% capture body %}}
|
||||||
## 컨트롤 플래인 컴포넌트
|
## 컨트롤 플레인 컴포넌트
|
||||||
|
|
||||||
컨트롤 플래인 컴포넌트는 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드에 대한 요구조건을 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동시키는 것)를 감지하고 반응한다.
|
컨트롤 플레인 컴포넌트는 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동시키는 것)를 감지하고 반응한다.
|
||||||
|
|
||||||
컨트롤 플래인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나
|
컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있다. 그러나
|
||||||
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플래인 컴포넌트를 구동시키고,
|
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고,
|
||||||
사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 다중-마스터-VM 설치 예제를 보려면
|
사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 다중-마스터-VM 설치 예제를 보려면
|
||||||
[고가용성 클러스터 구성하기](/docs/admin/high-availability/)를 확인해본다.
|
[고가용성 클러스터 구성하기](/docs/admin/high-availability/)를 확인해본다.
|
||||||
|
|
||||||
|
|
@ -49,7 +49,7 @@ card:
|
||||||
이들 컨트롤러는 다음을 포함한다.
|
이들 컨트롤러는 다음을 포함한다.
|
||||||
|
|
||||||
* 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
|
* 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
|
||||||
* 레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞는 수의 파드들을
|
* 레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을
|
||||||
유지시켜 주는 책임을 가진다.
|
유지시켜 주는 책임을 가진다.
|
||||||
* 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.)
|
* 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.)
|
||||||
* 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.
|
* 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.
|
||||||
|
|
@ -60,14 +60,14 @@ card:
|
||||||
|
|
||||||
cloud-controller-manager는 클라우드-제공사업자-특유 컨트롤러 루프만을 동작시킨다. 이 컨트롤러 루프는 kube-controller-manager에서 비활성 시켜야만 한다. kube-controller-manager를 구동시킬 때 `--cloud-provider` 플래그를 `external`로 설정함으로써 이 컨트롤러 루프를 비활성 시킬 수 있다.
|
cloud-controller-manager는 클라우드-제공사업자-특유 컨트롤러 루프만을 동작시킨다. 이 컨트롤러 루프는 kube-controller-manager에서 비활성 시켜야만 한다. kube-controller-manager를 구동시킬 때 `--cloud-provider` 플래그를 `external`로 설정함으로써 이 컨트롤러 루프를 비활성 시킬 수 있다.
|
||||||
|
|
||||||
cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드가 서로 독립적으로 발전시켜 나갈 수 있도록 해준다. 이전 릴리스에서는, 코어 쿠버네티스 코드가 기능상으로 클라우드-제공사업자-특유 코드에 대해 의존적이었다. 향후 릴리스에서, 클라우드 밴더에 따른 코드는 클라우드 밴더 자체에 의해 유지되도록 하여야만 하며, 쿠버네티스가 동작하는 동안 cloud-controller-manager에 연계되도록 하여야만 한다.
|
cloud-controller-manager는 클라우드 벤더 코드와 쿠버네티스 코드가 서로 독립적으로 발전시켜 나갈 수 있도록 해준다. 이전 릴리스에서는 코어 쿠버네티스 코드가 기능상으로 클라우드-제공사업자-특유 코드에 대해 의존적이었다. 향후 릴리스에서 클라우드 벤더만의 코드는 클라우드 벤더가 유지해야 하며, 쿠버네티스가 동작하는 동안 cloud-controller-manager에 연계되도록 해야 한다.
|
||||||
|
|
||||||
다음 컨트롤러들은 클라우드 제공사업자의 의존성을 갖는다.
|
다음 컨트롤러들은 클라우드 제공사업자의 의존성을 갖는다.
|
||||||
|
|
||||||
* 노드 컨트롤러: 노드가 응답을 멈추고 나서 클라우드 상에서 삭제되어 졌는지 확정하기 위해 클라우드 제공사업자에게 확인하는 것
|
* 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공사업자에게 확인하는 것
|
||||||
* 라우트 컨트롤러: 바탕을 이루는 클라우드 인프라에 경로를 구성하는 것
|
* 라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성하는 것
|
||||||
* 서비스 컨트롤러: 클라우드 제공사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것
|
* 서비스 컨트롤러: 클라우드 제공사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것
|
||||||
* 볼륨 컨트롤러: 볼륨의 생성, 부착 그리고 마운트 하는 것과 볼륨을 조정하기 위해 클라우드 제공사업자와 상호작용하는 것
|
* 볼륨 컨트롤러: 볼륨의 생성, 연결 그리고 마운트 하는 것과 오케스트레이션하기 위해 클라우드 제공사업자와 상호작용하는 것
|
||||||
|
|
||||||
## 노드 컴포넌트
|
## 노드 컴포넌트
|
||||||
|
|
||||||
|
|
@ -97,7 +97,7 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
|
||||||
|
|
||||||
### DNS
|
### DNS
|
||||||
|
|
||||||
여타 애드온들이 절대적으로 요구되지 않지만, 많은 예시에서 그것을 필요로 하기 때문에 모든 쿠버네티스 클러스터는 [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 갖추어야만 한다.
|
여타 애드온들이 절대적으로 요구되지 않지만, 많은 예시에서 필요로 하기 때문에 모든 쿠버네티스 클러스터는 [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 갖추어야만 한다.
|
||||||
|
|
||||||
클러스터 DNS는 구성환경 내 다른 DNS 서버와 더불어, 쿠버네티스 서비스를 위해 DNS 레코드를 제공해주는 DNS 서버다.
|
클러스터 DNS는 구성환경 내 다른 DNS 서버와 더불어, 쿠버네티스 서비스를 위해 DNS 레코드를 제공해주는 DNS 서버다.
|
||||||
|
|
||||||
|
|
@ -105,12 +105,12 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
|
||||||
|
|
||||||
### 웹 UI (대시보드)
|
### 웹 UI (대시보드)
|
||||||
|
|
||||||
[대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/)는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI다. 사용자가 클러스터 자체뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리와 고장처리를 할 수 있도록 허용해준다.
|
[대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/)는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI다. 사용자가 클러스터 자체뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리와 문제 해결을 할 수 있도록 해준다.
|
||||||
|
|
||||||
### 컨테이너 리소스 모니터링
|
### 컨테이너 리소스 모니터링
|
||||||
|
|
||||||
[컨테이너 리소스 모니터링](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은
|
[컨테이너 리소스 모니터링](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은
|
||||||
중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
|
중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
|
||||||
|
|
||||||
### 클러스터-레벨 로깅
|
### 클러스터-레벨 로깅
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -17,7 +17,7 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc
|
||||||
|
|
||||||
쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다.
|
쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다.
|
||||||
|
|
||||||
쿠버네티스는 또한 API 리소스에 대해 직렬화된 상태를 (현재는 [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)에) 저장한다.
|
쿠버네티스는 또한 API 리소스에 대해 직렬화된 상태를 (현재는 [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)에) 저장한다.
|
||||||
|
|
||||||
쿠버네티스 자체는 여러 컴포넌트로 나뉘어져서 각각의 API를 통해 상호작용한다.
|
쿠버네티스 자체는 여러 컴포넌트로 나뉘어져서 각각의 API를 통해 상호작용한다.
|
||||||
|
|
||||||
|
|
@ -28,7 +28,7 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc
|
||||||
|
|
||||||
## API 변경
|
## API 변경
|
||||||
|
|
||||||
경험에 따르면, 성공적인 시스템은 새로운 유스케이스의 등장과 기존의 유스케이스의 변경에 맞춰 성장하고 변경될 필요가 있다. 그래서, 쿠버네티스 API가 지속적으로 변경되고 성장하기를 바란다. 그러나, 일정 기간 동안은 현존하는 클라이언트와의 호환성을 깨지 않으려고 한다. 일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다. 리소스나 필드를 없애는 일은 다음의 [API deprecation policy](/docs/reference/using-api/deprecation-policy/)를 따른다.
|
경험에 따르면, 성공적인 시스템은 새로운 유스케이스의 등장과 기존 유스케이스의 변경에 맞춰 성장하고 변경될 필요가 있다. 그래서, 쿠버네티스 API가 지속적으로 변경되고 성장하기를 바란다. 그러나, 일정 기간 동안은 현재의 클라이언트와의 호환성을 깨지 않으려고 한다. 일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다. 리소스나 필드를 없애는 일은 다음의 [API deprecation policy](/docs/reference/using-api/deprecation-policy/)를 따른다.
|
||||||
|
|
||||||
호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)에 있다.
|
호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)에 있다.
|
||||||
|
|
||||||
|
|
@ -45,7 +45,7 @@ Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+
|
||||||
Accept-Encoding | `gzip` (이 헤더를 전달하지 않아도 됨)
|
Accept-Encoding | `gzip` (이 헤더를 전달하지 않아도 됨)
|
||||||
|
|
||||||
1.14 이전 버전에서 형식이 구분된 엔드포인트(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)는 OpenAPI 스펙을 다른 포맷으로 제공한다.
|
1.14 이전 버전에서 형식이 구분된 엔드포인트(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)는 OpenAPI 스펙을 다른 포맷으로 제공한다.
|
||||||
이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거됬다.
|
이러한 엔드포인트는 사용이 중단되었으며, 쿠버네티스 1.14에서 제거되었다.
|
||||||
|
|
||||||
**OpenAPI 규격을 조회하는 예제**
|
**OpenAPI 규격을 조회하는 예제**
|
||||||
|
|
||||||
|
|
@ -59,7 +59,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
|
||||||
|
|
||||||
1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/)
|
1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/)
|
||||||
쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다.
|
쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다.
|
||||||
이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거되었다.
|
이러한 엔드포인트는 사용이 중단되었으며, 쿠버네티스 1.14에서 제거되었다.
|
||||||
|
|
||||||
## API 버전 규칙
|
## API 버전 규칙
|
||||||
|
|
||||||
|
|
@ -88,7 +88,7 @@ API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르
|
||||||
- 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. 기본적으로 활성화되어 있다.
|
- 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. 기본적으로 활성화되어 있다.
|
||||||
- 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
|
- 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
|
||||||
- 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우,
|
- 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우,
|
||||||
다음 버전으로 이관할 수 있는 가이드를 제공할 것이다.
|
다음 버전으로 이관할 수 있는 가이드를 제공할 것이다.
|
||||||
이 때 API 오브젝트의 삭제, 편집 또는 재생성이 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
|
이 때 API 오브젝트의 삭제, 편집 또는 재생성이 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
|
||||||
- 다음 릴리스에서 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다.
|
- 다음 릴리스에서 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다.
|
||||||
복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면 이런 제약에서 안심이 될 수도 있겠다.
|
복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면 이런 제약에서 안심이 될 수도 있겠다.
|
||||||
|
|
@ -119,21 +119,22 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명
|
||||||
만들 수 있다.
|
만들 수 있다.
|
||||||
|
|
||||||
|
|
||||||
## API 그룹 활성화 시키기
|
## API 그룹 활성화 또는 비활성화하기
|
||||||
|
|
||||||
특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나
|
특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나
|
||||||
비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화 시키려면
|
비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화 시키려면
|
||||||
`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화 시키려면 `--runtime-config=batch/v2alpha1`을
|
`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화 시키려면 `--runtime-config=batch/v2alpha1`을
|
||||||
설정한다. 이 플래그는 apiserver의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
|
설정한다. 이 플래그는 apiserver의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
|
||||||
|
|
||||||
중요: 그룹이나 리소스를 활성화 또는 비활성화 시키기 위해서는 apiserver와 controller-manager를 재시작해서
|
{{< note >}}그룹이나 리소스를 활성화 또는 비활성화 시키기 위해서는 apiserver와 controller-manager를 재시작해서
|
||||||
`--runtime-config` 변경을 반영시켜야 한다.
|
`--runtime-config` 변경을 반영시켜야 한다. {{< /note >}}
|
||||||
|
|
||||||
## 그룹 내 리소스 활성화 시키기
|
## extensions/v1beta1 그룹 내 특정 리소스 활성화하기
|
||||||
|
|
||||||
데몬셋, 디플로이먼트, HorizontalPodAutoscaler, 인그레스, 잡 및 레플리카셋이 기본적으로 활성화되어 있다.
|
데몬셋, 디플로이먼트, 스테이트풀셋, 네트워크폴리시, 파드시큐리티폴리시 그리고 레플리카셋은 `extensions/v1beta1` API 그룹에서 기본적으로 비활성화되어있다.
|
||||||
다른 확장 리소스는 apiserver의 `--runtime-config`를 설정해서 활성화 시킬 수 있다.
|
예시: 디플로이먼트와 데몬셋의 활성화 설정은
|
||||||
`--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어 디플로이먼트와 인그레스를 비활성화 시키려면,
|
`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true` 를 입력한다.
|
||||||
`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`와 같이 설정한다.
|
|
||||||
|
{{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}}
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,7 @@
|
||||||
---
|
---
|
||||||
title: 쿠버네티스란 무엇인가
|
title: 쿠버네티스란 무엇인가
|
||||||
|
description: >
|
||||||
|
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 지원 그리고 도구들은 광범위하게 제공된다.
|
||||||
content_template: templates/concept
|
content_template: templates/concept
|
||||||
weight: 10
|
weight: 10
|
||||||
card:
|
card:
|
||||||
|
|
@ -14,9 +16,10 @@ card:
|
||||||
{{% capture body %}}
|
{{% capture body %}}
|
||||||
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.
|
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.
|
||||||
|
|
||||||
쿠버네티스란 명칭은 키잡이(helmsman)이나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 [구글의 15여년에 걸친 대규모 상용 워크로드 운영 경험](https://ai.google/research/pubs/pub43438)을 기반으로 만들어졌으며 커뮤니티의 최고의 아이디어와 적용 사례가 결합되었다.
|
쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다.
|
||||||
|
|
||||||
## 여정 돌아보기
|
## 여정 돌아보기
|
||||||
|
|
||||||
시간이 지나면서 쿠버네티스가 왜 유용하게 되었는지 살펴보자.
|
시간이 지나면서 쿠버네티스가 왜 유용하게 되었는지 살펴보자.
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -26,9 +29,9 @@ card:
|
||||||
|
|
||||||
**가상화된 배포 시대:** 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.
|
**가상화된 배포 시대:** 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.
|
||||||
|
|
||||||
가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다.
|
가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다.
|
||||||
|
|
||||||
각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 전체 시스템이다.
|
각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다.
|
||||||
|
|
||||||
**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
|
**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
|
||||||
|
|
||||||
|
|
@ -36,16 +39,16 @@ card:
|
||||||
|
|
||||||
* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
|
* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
|
||||||
* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 쉽게 롤백할 수 있다.
|
* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 쉽게 롤백할 수 있다.
|
||||||
* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 디커플된다.
|
* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
|
||||||
* 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
|
* 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
|
||||||
* 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
|
* 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
|
||||||
* 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine 및 다른 어디에서든 구동된다.
|
* 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
|
||||||
* 애플리케이션 중심 관리: 가상 하드웨어의 OS에서 애플리케이션을 구동하는 수준에서 OS의 논리적인 자원을 사용하여 애플리케이션을 구동하는 수준으로 추상화 수준이 높아진다.
|
* 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
|
||||||
* 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
|
* 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
|
||||||
* 자원 격리: 애플리케이션 성능을 예측할 수 있다.
|
* 리소스 격리: 애플리케이션 성능을 예측할 수 있다.
|
||||||
* 자원 사용량: 고효율 고집적.
|
* 자원 사용량: 리소스 사용량: 고효율 고집적.
|
||||||
|
|
||||||
## 쿠버네티스가 왜 필요하고 무엇을 할 수 있나
|
## 쿠버네티스가 왜 필요하고 무엇을 할 수 있나 {#why-you-need-kubernetes-and-what-can-it-do}
|
||||||
|
|
||||||
컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
|
컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
|
||||||
|
|
||||||
|
|
@ -64,11 +67,11 @@ card:
|
||||||
* **자동화된 복구(self-healing)**
|
* **자동화된 복구(self-healing)**
|
||||||
쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
|
쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
|
||||||
* **시크릿과 구성 관리**
|
* **시크릿과 구성 관리**
|
||||||
쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
|
쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
|
||||||
|
|
||||||
## 쿠버네티스가 아닌 것
|
## 쿠버네티스가 아닌 것
|
||||||
|
|
||||||
쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 같은 기능에서 공통점이 있기도 하다. 하지만, 쿠버네티스는 모놀리식(monolithic)하지 않아서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.
|
쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 같은 기능에서 공통점이 있기도 하다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.
|
||||||
|
|
||||||
쿠버네티스는:
|
쿠버네티스는:
|
||||||
|
|
||||||
|
|
@ -78,7 +81,7 @@ card:
|
||||||
* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
|
* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
|
||||||
* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
|
* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
|
||||||
* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
|
* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
|
||||||
* 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
|
* 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ title: 필드 셀렉터
|
||||||
weight: 60
|
weight: 60
|
||||||
---
|
---
|
||||||
|
|
||||||
_필드 셀렉터_ 는 한 개 이상의 리소스 필드 값에 따라 [쿠버네티스 리소스를 선택](/docs/concepts/overview/working-with-objects/kubernetes-objects)하기 위해 사용된다. 필드 셀렉터 쿼리의 예시는 다음과 같다.
|
_필드 셀렉터_ 는 한 개 이상의 리소스 필드 값에 따라 [쿠버네티스 리소스를 선택](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)하기 위해 사용된다. 필드 셀렉터 쿼리의 예시는 다음과 같다.
|
||||||
|
|
||||||
* `metadata.name=my-service`
|
* `metadata.name=my-service`
|
||||||
* `metadata.namespace!=default`
|
* `metadata.namespace!=default`
|
||||||
|
|
@ -45,7 +45,7 @@ kubectl get services --all-namespaces --field-selector metadata.namespace!=defa
|
||||||
|
|
||||||
## 연계되는 셀렉터
|
## 연계되는 셀렉터
|
||||||
|
|
||||||
[레이블](/docs/concepts/overview/working-with-objects/labels)을 비롯한 다른 셀렉터처럼, 쉼표로 구분되는 목록을 통해 필드 셀렉터를 연계해서 사용할 수 있다. 다음의 `kubectl` 커맨드는 `status.phase` 필드가 `Running` 이 아니고, `spec.restartPolicy` 필드가 `Always` 인 모든 파드를 선택한다.
|
[레이블](/ko/docs/concepts/overview/working-with-objects/labels)을 비롯한 다른 셀렉터처럼, 쉼표로 구분되는 목록을 통해 필드 셀렉터를 연계해서 사용할 수 있다. 다음의 `kubectl` 커맨드는 `status.phase` 필드가 `Running` 이 아니고, `spec.restartPolicy` 필드가 `Always` 인 모든 파드를 선택한다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
|
kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
|
||||||
|
|
|
||||||
|
|
@ -20,29 +20,45 @@ card:
|
||||||
* 그 애플리케이션이 이용할 수 있는 리소스
|
* 그 애플리케이션이 이용할 수 있는 리소스
|
||||||
* 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책
|
* 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책
|
||||||
|
|
||||||
쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드" 이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 *의도한 상태* 가 된다.
|
쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드"이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 *의도한 상태* 가 된다.
|
||||||
|
|
||||||
생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, `kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
|
생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, `kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
|
||||||
|
|
||||||
### 오브젝트 스펙(spec)과 상태(status)
|
### 오브젝트 명세(spec)와 상태(status)
|
||||||
|
|
||||||
모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 *spec* 과 오브젝트 *status* 가 그것이다. 필히 제공되어야만 하는 *spec* 은, 여러분이 오브젝트가 가졌으면 하고 원하는 특징, 즉 의도한 상태를 기술한다. *status* 는 오브젝트의 *실제 상태* 를 기술하고, 쿠버네티스 시스템에 의해 제공되고 업데이트 된다. 주어진 임의의 시간에, 쿠버네티스 컨트롤 플레인은 오브젝트의 실제 상태를 여러분이 제시한 의도한 상태에 일치시키기 위해 능동적으로 관리한다.
|
거의 모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는
|
||||||
|
두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 *`spec`* 과 오브젝트 *`status`* 이다.
|
||||||
|
`spec`을 가진 오브젝트는 오브젝트를 생성할 때 리소스에
|
||||||
|
원하는 특징(_의도한 상태_)에 대한 설명을
|
||||||
|
제공해서 설정한다.
|
||||||
|
|
||||||
|
`status`는 오브젝트의 _현재 상태_ 를 기술하고, 쿠버네티스
|
||||||
|
컴포넌트에 의해 제공되고 업데이트 된다. 쿠버네티스
|
||||||
|
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 모든 오브젝트의
|
||||||
|
실제 상태를 사용자가 의도한 상태와 일치시키기 위해 끊임없이 그리고
|
||||||
|
능동적으로 관리한다.
|
||||||
|
|
||||||
예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을 표현해 줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트 spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 (상태 변경에) 실패가 난다면, 쿠버네티스 시스템은 보정을 통해, 이 경우에는 인스턴스 대체를 착수하여, spec과 status 간의 차이에 대응한다.
|
예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을
|
||||||
|
표현해줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트
|
||||||
|
spec에 3개의 애플리케이션 레플리카가 동작되도록
|
||||||
|
설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어
|
||||||
|
spec에 일치되도록 상태를 업데이트하여 3개의 의도한
|
||||||
|
애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가
|
||||||
|
(상태 변경에) 실패한다면, 쿠버네티스 시스템은 보정(이 경우에는 대체 인스턴스를 시작하여)을 통해
|
||||||
|
spec과 status 간의 차이에 대응한다.
|
||||||
|
|
||||||
오브젝트 spec, staus, 그리고 metadata에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다.
|
오브젝트 명세, 상태, 그리고 메타데이터에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다.
|
||||||
|
|
||||||
### 쿠버네티스 오브젝트 기술하기
|
### 쿠버네티스 오브젝트 기술하기
|
||||||
|
|
||||||
쿠버네티스에서 오브젝트를 생성할 때, (이름과 같은)오브젝트에 대한 기본적인 정보와 더불어, 의도한 상태를 기술한 오브젝트 spec을 제시해 줘야만 한다. 오브젝트를 생성하기 위해(직접이든 또는 `kubectl`을 통해서든) 쿠버네티스 API를 이용할 때, API 요청은 요청 내용 안에 JSON 형식으로 정보를 포함시켜 줘야만 한다. **가장 자주, .yaml 파일로 `kubectl`에 정보를 제공해준다.** `kubectl` 은 API 요청이 이루어질 때, JSON 형식으로 정보를 변환시켜 준다.
|
쿠버네티스에서 오브젝트를 생성할 때, (이름과 같은)오브젝트에 대한 기본적인 정보와 더불어, 의도한 상태를 기술한 오브젝트 spec을 제시해 줘야만 한다. 오브젝트를 생성하기 위해(직접이든 또는 `kubectl`을 통해서든) 쿠버네티스 API를 이용할 때, API 요청은 요청 내용 안에 JSON 형식으로 정보를 포함시켜 줘야만 한다. **대부분의 경우 정보를 .yaml 파일로 `kubectl`에 제공한다.** `kubectl`은 API 요청이 이루어질 때, JSON 형식으로 정보를 변환시켜 준다.
|
||||||
|
|
||||||
여기 쿠버네티스 디플로이먼트를 위한 요청 필드와 오브젝트 spec을 보여주는 `.yaml` 파일 예시가 있다.
|
여기 쿠버네티스 디플로이먼트를 위한 요청 필드와 오브젝트 spec을 보여주는 `.yaml` 파일 예시가 있다.
|
||||||
|
|
||||||
{{< codenew file="application/deployment.yaml" >}}
|
{{< codenew file="application/deployment.yaml" >}}
|
||||||
|
|
||||||
위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는
|
위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는
|
||||||
`kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네
|
`kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일을 건네
|
||||||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다.
|
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
|
|
@ -61,7 +77,7 @@ deployment.apps/nginx-deployment created
|
||||||
|
|
||||||
* `apiVersion` - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
|
* `apiVersion` - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
|
||||||
* `kind` - 어떤 종류의 오브젝트를 생성하고자 하는지
|
* `kind` - 어떤 종류의 오브젝트를 생성하고자 하는지
|
||||||
* `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스` 를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
|
* `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스`를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
|
||||||
* `spec` - 오브젝트에 대해 어떤 상태를 의도하는지
|
* `spec` - 오브젝트에 대해 어떤 상태를 의도하는지
|
||||||
|
|
||||||
오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
|
오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
|
||||||
|
|
@ -78,4 +94,3 @@ deployment.apps/nginx-deployment created
|
||||||
* 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
|
* 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -27,11 +27,11 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
|
||||||
|
|
||||||
{{% capture body %}}
|
{{% capture body %}}
|
||||||
|
|
||||||
## 사용동기
|
## 사용 동기
|
||||||
|
|
||||||
레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.
|
레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.
|
||||||
|
|
||||||
서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔터티들이다(예: 다중파티션 또는 배포, 다중 릴리즈 트랙, 다중 계층, 계층속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.
|
서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔티티들이다(예: 다중 파티션 또는 배포, 다중 릴리즈 트랙, 다중 계층, 계층 속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.
|
||||||
|
|
||||||
레이블 예시:
|
레이블 예시:
|
||||||
|
|
||||||
|
|
@ -41,17 +41,17 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
|
||||||
* `"partition" : "customerA"`, `"partition" : "customerB"`
|
* `"partition" : "customerA"`, `"partition" : "customerB"`
|
||||||
* `"track" : "daily"`, `"track" : "weekly"`
|
* `"track" : "daily"`, `"track" : "weekly"`
|
||||||
|
|
||||||
레이블 예시는 일반적으로 사용하는 경우에 해당한다. 당신의 규약에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야한다는 것을 기억해야한다.
|
레이블 예시는 일반적으로 사용하는 상황에 해당한다. 당신의 규약에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
|
||||||
|
|
||||||
## 구문과 캐릭터 셋
|
## 구문과 캐릭터 셋
|
||||||
|
|
||||||
_레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(`/`)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야하며, 점(`.`)과, 전체 253자 이하, 슬래시(`/`)로 구분되는 DNS 레이블이다.
|
_레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(`/`)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야 하며, 점(`.`)과 전체 253자 이하, 슬래시(`/`)로 구분되는 DNS 레이블이다.
|
||||||
|
|
||||||
접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 구성 요소(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
|
접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
|
||||||
|
|
||||||
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 구성요소로 예약되어있다.
|
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
|
||||||
|
|
||||||
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
|
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
|
||||||
|
|
||||||
다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.
|
다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.
|
||||||
|
|
||||||
|
|
@ -83,10 +83,10 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
|
||||||
레이블 셀렉터는 쉼표로 구분된 다양한 _요구사항_ 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(`&&`) 연산자로 구분되는 역할을 하도록 해야 한다.
|
레이블 셀렉터는 쉼표로 구분된 다양한 _요구사항_ 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(`&&`) 연산자로 구분되는 역할을 하도록 해야 한다.
|
||||||
|
|
||||||
비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다.
|
비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다.
|
||||||
셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화 해야 한다.
|
셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화해야 한다.
|
||||||
|
|
||||||
{{< note >}}
|
{{< note >}}
|
||||||
레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충되는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
|
레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
|
||||||
{{< /note >}}
|
{{< /note >}}
|
||||||
|
|
||||||
{{< caution >}}
|
{{< caution >}}
|
||||||
|
|
@ -96,23 +96,21 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
|
||||||
|
|
||||||
### _일치성 기준_ 요건
|
### _일치성 기준_ 요건
|
||||||
|
|
||||||
_일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만 레이블의 명시된 제약 조건을 모두 만족해야 한다.
|
_일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만, 레이블의 명시된 제약 조건을 모두 만족해야 한다.
|
||||||
`=`,`==`,`!=` 이 3가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 단순히 동의어일 뿐임), 나머지는 _불일치_를 의미한다. 예를 들면,
|
`=`,`==`,`!=` 이 3가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 단순히 동의어일 뿐임), 나머지는 _불일치_ 를 의미한다. 예를 들면,
|
||||||
|
|
||||||
```
|
```
|
||||||
environment = production
|
environment = production
|
||||||
tier != frontend
|
tier != frontend
|
||||||
```
|
```
|
||||||
|
|
||||||
전자는 `environment`를 키로 가지는 것과 `production`를 값으로 가지는 모든 리소스를 선택한다.
|
전자는 `environment`를 키로 가지는 것과 `production`을 값으로 가지는 모든 리소스를 선택한다.
|
||||||
후자는 `tier`를 키로 가지고, 값을 `frontend`를 가지는 리소스를 제외한 모든 리소스를 선택하고, `tier`를 키로 가지며, 값을 공백으로 가지는 모든 리소스를 선택한다.
|
후자는 `tier`를 키로 가지고, 값을 `frontend`를 가지는 리소스를 제외한 모든 리소스를 선택하고, `tier`를 키로 가지며, 값을 공백으로 가지는 모든 리소스를 선택한다.
|
||||||
`environment=production,tier!=frontend` 처럼 쉼표를 통해 한 문장으로 `frontend`를 제외한 `production`을 필터링할 수 있다.
|
`environment=production,tier!=frontend` 처럼 쉼표를 통해 한 문장으로 `frontend`를 제외한 `production`을 필터링할 수 있다.
|
||||||
|
|
||||||
균등-기반 레이블의 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다.
|
균등-기반 레이블의 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다.
|
||||||
예를 들어, 아래 샘플 파드는 "`accelerator=nvidia-tesla-p100`" 레이블을 가진 노드를 선택한다.
|
예를 들어, 아래 샘플 파드는 "`accelerator=nvidia-tesla-p100`" 레이블을 가진 노드를 선택한다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: Pod
|
kind: Pod
|
||||||
|
|
@ -141,11 +139,11 @@ partition
|
||||||
```
|
```
|
||||||
|
|
||||||
첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다.
|
첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다.
|
||||||
두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와, 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
|
두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
|
||||||
세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`를 포함하는 모든 리소스를 선택한다.
|
세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하는 모든 리소스를 선택한다.
|
||||||
네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`를 포함하지 않는 모든 리소스를 선택한다.
|
네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하지 않는 모든 리소스를 선택한다.
|
||||||
마찬가지로 쉼표는 _AND_ 연산자로 작동한다. 따라서 `partition,environment notin (qa)`와 같이 사용하면 값과 상관없이 키가 `partition`인 것과 키가 `environment`이고 값이 `qa`와 다른 리소스를 필터링할 수 있다.
|
마찬가지로 쉼표는 _AND_ 연산자로 작동한다. 따라서 `partition,environment notin (qa)`와 같이 사용하면 값과 상관없이 키가 `partition`인 것과 키가 `environment`이고 값이 `qa`와 다른 리소스를 필터링할 수 있다.
|
||||||
_집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=production` 과 `environment in (production)`를 같은 것으로 본다. 유사하게는 `!=`과 `notin`을 같은 것으로 본다.
|
_집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=production`과 `environment in (production)`을 같은 것으로 본다. 유사하게는 `!=`과 `notin`을 같은 것으로 본다.
|
||||||
|
|
||||||
_집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할 수 있다. 예를 들어 `partition in (customerA, customerB),environment!=qa`
|
_집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할 수 있다. 예를 들어 `partition in (customerA, customerB),environment!=qa`
|
||||||
|
|
||||||
|
|
@ -158,7 +156,7 @@ LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브
|
||||||
* _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
|
* _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
|
||||||
* _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
|
* _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
|
||||||
|
|
||||||
두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, `kubectl`로 `API 서버`를 대상으로 _불일치 기준_으로 하는 셀렉터를 다음과 같이 이용할 수 있다.
|
두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, `kubectl`로 `apiserver`를 대상으로 _불일치 기준_ 으로 하는 셀렉터를 다음과 같이 이용할 수 있다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl get pods -l environment=production,tier=frontend
|
kubectl get pods -l environment=production,tier=frontend
|
||||||
|
|
@ -184,11 +182,11 @@ kubectl get pods -l 'environment,environment notin (frontend)'
|
||||||
|
|
||||||
### API 오브젝트에서 참조 설정
|
### API 오브젝트에서 참조 설정
|
||||||
|
|
||||||
[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다.
|
[`services`](/ko/docs/concepts/services-networking/service/) 와 [`replicationcontrollers`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [파드](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다.
|
||||||
|
|
||||||
#### 서비스와 레플리케이션 컨트롤러
|
#### 서비스와 레플리케이션 컨트롤러
|
||||||
|
|
||||||
`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `레플리케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
|
`services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
|
||||||
|
|
||||||
서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.
|
서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.
|
||||||
|
|
||||||
|
|
@ -209,7 +207,7 @@ selector:
|
||||||
|
|
||||||
#### 세트-기반 요건을 지원하는 리소스
|
#### 세트-기반 요건을 지원하는 리소스
|
||||||
|
|
||||||
[`잡`](/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
|
[`Job`](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/), [`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
selector:
|
selector:
|
||||||
|
|
@ -220,7 +218,7 @@ selector:
|
||||||
- {key: environment, operator: NotIn, values: [dev]}
|
- {key: environment, operator: NotIn, values: [dev]}
|
||||||
```
|
```
|
||||||
|
|
||||||
`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`과 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다.
|
`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다.
|
||||||
|
|
||||||
#### 노드 셋 선택
|
#### 노드 셋 선택
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -9,9 +9,9 @@ weight: 20
|
||||||
클러스터의 각 오브젝트는 해당 유형의 리소스에 대하여 고유한 [_이름_](#names) 을 가지고 있다.
|
클러스터의 각 오브젝트는 해당 유형의 리소스에 대하여 고유한 [_이름_](#names) 을 가지고 있다.
|
||||||
또한, 모든 쿠버네티스 오브젝트는 전체 클러스터에 걸쳐 고유한 [_UID_](#uids) 를 가지고 있다.
|
또한, 모든 쿠버네티스 오브젝트는 전체 클러스터에 걸쳐 고유한 [_UID_](#uids) 를 가지고 있다.
|
||||||
|
|
||||||
예를 들어, 이름이 `myapp-1234`인 파드는 동일한 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) 내에서 하나만 가질 수 있지만, 이름이 `myapp-1234`인 파드와 디플로이먼트는 각각 가질 수 있다.
|
예를 들어, 이름이 `myapp-1234`인 파드는 동일한 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) 내에서 하나만 존재할 수 있지만, 이름이 `myapp-1234`인 파드와 디플로이먼트는 각각 존재할 수 있다.
|
||||||
|
|
||||||
유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)과 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.
|
유일하지 않은 사용자 제공 속성의 경우 쿠버네티스는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)과 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
@ -22,9 +22,9 @@ weight: 20
|
||||||
|
|
||||||
{{< glossary_definition term_id="name" length="all" >}}
|
{{< glossary_definition term_id="name" length="all" >}}
|
||||||
|
|
||||||
다음은 리소스에 일반적으로 사용되는 세가지 유형의 이름 제한 조건이다.
|
다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.
|
||||||
|
|
||||||
### DNS 서브도메인 이름들
|
### DNS 서브도메인 이름
|
||||||
|
|
||||||
대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로
|
대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로
|
||||||
DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
|
DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
|
||||||
|
|
@ -52,7 +52,7 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
|
||||||
있어야 한다. 즉 이름이 "." 또는 ".."이 아닐 수 있으며 이름에는
|
있어야 한다. 즉 이름이 "." 또는 ".."이 아닐 수 있으며 이름에는
|
||||||
"/" 또는 "%"가 포함될 수 없다.
|
"/" 또는 "%"가 포함될 수 없다.
|
||||||
|
|
||||||
여기 파드의 이름이 `nginx-demo`라는 매니페스트 예시가 있다.
|
아래는 파드의 이름이 `nginx-demo`라는 매니페스트 예시이다.
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
|
|
|
||||||
|
|
@ -6,33 +6,33 @@ weight: 30
|
||||||
|
|
||||||
{{% capture overview %}}
|
{{% capture overview %}}
|
||||||
|
|
||||||
쿠버네티스는 동일 물리 클러스터를 기반으로 하는 복수의 가상 클러스터를 지원한다.
|
쿠버네티스는 동일한 물리 클러스터를 기반으로 하는 여러 가상 클러스터를 지원한다.
|
||||||
이들 가상 클러스터를 네임스페이스라고 한다.
|
이런 가상 클러스터를 네임스페이스라고 한다.
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
||||||
{{% capture body %}}
|
{{% capture body %}}
|
||||||
|
|
||||||
## 복수의 네임스페이스를 사용하는 경우
|
## 여러 개의 네임스페이스를 사용하는 경우
|
||||||
|
|
||||||
네임스페이스는 복수의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록
|
네임스페이스는 여러 개의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록
|
||||||
만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는,
|
만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는
|
||||||
네임스페이스를 고려할 필요가 전혀 없다.
|
네임스페이스를 전혀 고려할 필요가 없다.
|
||||||
네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자.
|
네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자.
|
||||||
|
|
||||||
네임스페이스는 이름의 범위를 제공한다.
|
네임스페이스는 이름의 범위를 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야하지만,
|
||||||
리소스의 이름은 네임스페이스 내에서 유일해야하지만,
|
네임스페이스를 통틀어서 유일할 필요는 없다. 네임스페이스는 서로 중첩될 수 없으며,
|
||||||
네임스페이스를 통틀어서 유일할 필요는 없다.
|
각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다.
|
||||||
|
|
||||||
네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다.
|
네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 여러 사용자 사이에서 나누는 방법이다.
|
||||||
|
|
||||||
다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적으로 동일한 접근 제어 정책을 갖게 된다.
|
이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로
|
||||||
네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다.
|
동일한 접근 제어 정책을 갖게 된다.
|
||||||
|
|
||||||
같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서
|
동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해
|
||||||
복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를
|
여러 네임스페이스를 사용할 필요는 없다. 동일한 네임스페이스 내에서 리소스를
|
||||||
구분하기 위해서는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 사용한다.
|
구별하기 위해 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 사용한다.
|
||||||
|
|
||||||
## 네임스페이스 다루기
|
## 네임스페이스 다루기
|
||||||
|
|
||||||
|
|
@ -41,7 +41,7 @@ weight: 30
|
||||||
|
|
||||||
### 네임스페이스 조회
|
### 네임스페이스 조회
|
||||||
|
|
||||||
사용중인 클러스터의 현재 네임스페이스를 나열할 수 있다.
|
사용 중인 클러스터의 현재 네임스페이스를 나열할 수 있다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl get namespace
|
kubectl get namespace
|
||||||
|
|
@ -61,7 +61,7 @@ kube-public Active 1d
|
||||||
|
|
||||||
### 요청에 네임스페이스 설정하기
|
### 요청에 네임스페이스 설정하기
|
||||||
|
|
||||||
네임스페이스를 현재 요청에 설정하기 위해서는, `--namespace` 플래그를 사용한다.
|
현재 요청에 대한 네임스페이스를 설정하기 위해서 `--namespace` 플래그를 사용한다.
|
||||||
|
|
||||||
예를 들면,
|
예를 들면,
|
||||||
|
|
||||||
|
|
@ -72,7 +72,7 @@ kubectl get pods --namespace=<insert-namespace-name-here>
|
||||||
|
|
||||||
### 선호하는 네임스페이스 설정하기
|
### 선호하는 네임스페이스 설정하기
|
||||||
|
|
||||||
이후 모든 kubectl 명령에서 사용될 네임스페이스를 컨텍스트에
|
이후 모든 kubectl 명령에서 사용하는 네임스페이스를 컨텍스트에
|
||||||
영구적으로 저장할 수 있다.
|
영구적으로 저장할 수 있다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
|
|
@ -83,7 +83,7 @@ kubectl config view --minify | grep namespace:
|
||||||
|
|
||||||
## 네임스페이스와 DNS
|
## 네임스페이스와 DNS
|
||||||
|
|
||||||
[서비스](/docs/user-guide/services)를 생성하면, 대응되는
|
[서비스](/docs/user-guide/services)를 생성하면 해당
|
||||||
[DNS 엔트리](/ko/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
|
[DNS 엔트리](/ko/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
|
||||||
이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데,
|
이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데,
|
||||||
이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.
|
이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.
|
||||||
|
|
@ -94,10 +94,10 @@ kubectl config view --minify | grep namespace:
|
||||||
|
|
||||||
대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는
|
대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는
|
||||||
네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다.
|
네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다.
|
||||||
그리고 [nodes](/ko/docs/concepts/architecture/nodes/)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
|
그리고 [노드](/ko/docs/concepts/architecture/nodes/)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
|
||||||
네임스페이스에도 속하지 않는다.
|
네임스페이스에도 속하지 않는다.
|
||||||
|
|
||||||
네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하기 위해서는,
|
다음은 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하는 방법이다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
# 네임스페이스에 속하는 리소스
|
# 네임스페이스에 속하는 리소스
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@ weight: 15
|
||||||
{{% capture overview %}}
|
{{% capture overview %}}
|
||||||
`kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
|
`kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
|
||||||
몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을
|
몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을
|
||||||
제공한다. Kubectl으로 오브젝트 관리하기에 대한 자세한 설명은
|
제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은
|
||||||
[Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다.
|
[Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다.
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
@ -16,7 +16,7 @@ weight: 15
|
||||||
## 관리 기법
|
## 관리 기법
|
||||||
|
|
||||||
{{< warning >}}
|
{{< warning >}}
|
||||||
쿠버네티스 오브젝트는 오직 하나의 기법을 사용하여 관리되어야 한다. 동일한 오브젝트에
|
쿠버네티스 오브젝트는 하나의 기법만 사용하여 관리해야 한다. 동일한 오브젝트에
|
||||||
대해 혼합하고 일치시키는 기법은 확실하지 않은 동작을 초래하게 된다.
|
대해 혼합하고 일치시키는 기법은 확실하지 않은 동작을 초래하게 된다.
|
||||||
{{< /warning >}}
|
{{< /warning >}}
|
||||||
|
|
||||||
|
|
@ -26,10 +26,10 @@ weight: 15
|
||||||
| Imperative object configuration | Individual files | Production projects | 1 | Moderate |
|
| Imperative object configuration | Individual files | Production projects | 1 | Moderate |
|
||||||
| Declarative object configuration | Directories of files | Production projects | 1+ | Highest |
|
| Declarative object configuration | Directories of files | Production projects | 1+ | Highest |
|
||||||
|
|
||||||
## 명령형 명령어
|
## 명령형 커맨드
|
||||||
|
|
||||||
명령형 명령어를 사용할 경우, 사용자는 클러스터 내 활성 오브젝트를 대상으로
|
명령형 커맨드를 사용할 경우, 사용자는 클러스터 내 활성 오브젝트를 대상으로
|
||||||
직접 동작시킨다. 사용자는 `kubectl` 명령어에 인수 또는 플래그로 작업을
|
직접 동작시킨다. 사용자는 `kubectl` 커맨드에 인수 또는 플래그로 작업을
|
||||||
제공한다.
|
제공한다.
|
||||||
|
|
||||||
이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한
|
이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한
|
||||||
|
|
@ -52,21 +52,21 @@ kubectl create deployment nginx --image nginx
|
||||||
|
|
||||||
### 트레이드 오프
|
### 트레이드 오프
|
||||||
|
|
||||||
오브젝트 구성과 비교한 장점은
|
오브젝트 구성에 비해 장점은 다음과 같다.
|
||||||
|
|
||||||
- 명령어가 익히기에 단순, 용이하고 기억하기 쉽다.
|
- 커맨드는 간단해서 배우기 쉽고, 기억하기 쉽다.
|
||||||
- 명령어가 클러스터에 변경을 주기 위해 오직 단일 과정만이 필요하다.
|
- 커맨드는 클러스터를 수정하기 위해 단 하나의 단계만을 필요로 한다.
|
||||||
|
|
||||||
오브젝트 구성과 비교한 단점은
|
오브젝트 구성에 비해 단점은 다음과 같다.
|
||||||
|
|
||||||
- 명령어가 변경 검토 프로세스와 통합되지 않는다.
|
- 커맨드는 변경 검토 프로세스와 통합되지 않는다.
|
||||||
- 명령어가 변경에 관한 감사 추적을 제공하지 않는다.
|
- 커맨드는 변경에 관한 감사 추적(audit trail)을 제공하지 않는다.
|
||||||
- 명렁어가 활성 동작 중인 경우를 제외하고는 레코드의 소스를 제공하지 않는다.
|
- 커맨드는 활성 동작 중인 경우를 제외하고는 레코드의 소스를 제공하지 않는다.
|
||||||
- 명령어가 새로운 오브젝트 생성을 위한 템플릿을 제공하지 않는다.
|
- 커맨드는 새로운 오브젝트 생성을 위한 템플릿을 제공하지 않는다.
|
||||||
|
|
||||||
## 명령형 오브젝트 구성
|
## 명령형 오브젝트 구성
|
||||||
|
|
||||||
명령형 오브젝트 구성에서, kubectl 명령은 작업 (생성, 대체 등),
|
명령형 오브젝트 구성에서 kubectl 커맨드는 작업(생성, 교체 등),
|
||||||
선택적 플래그, 그리고 최소 하나의 파일 이름을 정의한다.
|
선택적 플래그, 그리고 최소 하나의 파일 이름을 정의한다.
|
||||||
그 파일은 YAML 또는 JSON 형식으로 오브젝트의 완전한 정의를
|
그 파일은 YAML 또는 JSON 형식으로 오브젝트의 완전한 정의를
|
||||||
포함해야만 한다.
|
포함해야만 한다.
|
||||||
|
|
@ -75,12 +75,12 @@ kubectl create deployment nginx --image nginx
|
||||||
참고한다.
|
참고한다.
|
||||||
|
|
||||||
{{< warning >}}
|
{{< warning >}}
|
||||||
명령형 `replace` 명령은 기존 spec을 새롭게 제공된 것으로 대체하며,
|
명령형 `replace` 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고
|
||||||
구성 파일에서 누락된 오브젝트에 대한 모든 변경사항은 없어진다.
|
구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다.
|
||||||
이러한 접근은 구성 파일에 대해 독립적으로 spec이 업데이트되는
|
이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는
|
||||||
형태의 리소스와 함께 사용하면 안된다.
|
사용하지 말아야한다.
|
||||||
예를 들어, `LoadBalancer` 형태의 서비스는 `externalIPs` 필드를
|
예를 들어 `LoadBalancer` 유형의 서비스는 클러스터의 구성과 별도로
|
||||||
클러스터 구성과는 독립적으로 업데이트한다.
|
`externalIPs` 필드가 업데이트된다.
|
||||||
{{< /warning >}}
|
{{< /warning >}}
|
||||||
|
|
||||||
### 예시
|
### 예시
|
||||||
|
|
@ -97,7 +97,7 @@ kubectl create -f nginx.yaml
|
||||||
kubectl delete -f nginx.yaml -f redis.yaml
|
kubectl delete -f nginx.yaml -f redis.yaml
|
||||||
```
|
```
|
||||||
|
|
||||||
활성 동작하는 구성을 덮어씀으로서 구성 파일에 정의된 오브젝트를
|
활성 동작하는 구성을 덮어씀으로써 구성 파일에 정의된 오브젝트를
|
||||||
업데이트한다.
|
업데이트한다.
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
|
|
@ -106,41 +106,42 @@ kubectl replace -f nginx.yaml
|
||||||
|
|
||||||
### 트레이드 오프
|
### 트레이드 오프
|
||||||
|
|
||||||
명령형 명령과 비교한 장점은
|
명령형 커맨드에 비해 장점은 다음과 같다.
|
||||||
|
|
||||||
- 오브젝트 구성이 Git과 같은 소스 컨트롤 시스템에 보관되어 질 수 있다.
|
- 오브젝트 구성은 Git과 같은 소스 컨트롤 시스템에 보관할 수 있다.
|
||||||
- 오브젝트 구성은 푸시와 감사 추적 전에 변경사항을 검토하는 것과 같은 프로세스들과 통합할 수 있다.
|
- 오브젝트 구성은 푸시와 감사 추적 전에 변경사항을 검토하는 것과 같은 프로세스들과 통합할 수 있다.
|
||||||
- 오브젝트 구성이 새로운 오브젝트 생성을 위한 템플릿을 제공한다.
|
- 오브젝트 구성은 새로운 오브젝트 생성을 위한 템플릿을 제공한다.
|
||||||
|
|
||||||
명령형 명령과 비교한 단점은
|
명령형 커맨드에 비해 단점은 다음과 같다.
|
||||||
|
|
||||||
- 오브젝트 구성이 오브젝트 스키마에 대한 기본적인 이해를 필요로 한다.
|
- 오브젝트 구성은 오브젝트 스키마에 대한 기본적인 이해를 필요로 한다.
|
||||||
- 오브젝트 구성이 YAML 파일을 기록하는 추가적인 과정을 필요로 한다.
|
- 오브젝트 구성은 YAML 파일을 기록하는 추가적인 과정을 필요로 한다.
|
||||||
|
|
||||||
선언형 오브젝트 구성과 비교한 장점은
|
선언형 오브젝트 구성에 비해 장점은 다음과 같다.
|
||||||
|
|
||||||
- 명령형 오브젝트 구성의 작용은 보다 간결하고 이해하기에 용이하다.
|
- 명령형 오브젝트 구성의 동작은 보다 간결하고 이해하기 쉽다.
|
||||||
- 쿠버네티스 버전 1.5 부터, 명령형 오브젝트 구성이 더욱 발달한다.
|
- 쿠버네티스 버전 1.5 부터는 더 성숙한 명령형 오브젝트 구성을 제공한다.
|
||||||
|
|
||||||
선언형 오브젝트 구성과 비교한 단점은
|
선언형 오브젝트 구성에 비해 단점은 다음과 같다.
|
||||||
|
|
||||||
- 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다.
|
- 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다.
|
||||||
- 활성 오브젝트에 대한 업데이트는 구성 파일 내 반영되어야만 한다. 그렇지 않으면 다음 대체가 이루어지는 동안 유실 될 것이다.
|
- 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다.
|
||||||
|
|
||||||
|
|
||||||
## 선언형 오브젝트 구성
|
## 선언형 오브젝트 구성
|
||||||
|
|
||||||
선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트
|
선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트
|
||||||
구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할
|
구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할
|
||||||
작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은
|
작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은
|
||||||
`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이것은 다른 오브젝트를 위해 필요할 수도 있는
|
`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해
|
||||||
다른 작업에서, 디렉토리들을 대상으로 동작할 수 있도록 해준다.
|
다른 조작이 필요할 수 있는 디렉토리에서 작업할 수 있다.
|
||||||
|
|
||||||
{{< note >}}
|
{{< note >}}
|
||||||
선언형 오브젝트 구성은 비록 그 변경사항이 오브젝트 구성 파일로
|
선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에
|
||||||
되돌려 병합될 수 없기는 하지만, 다른 작성자에 의해 이루어진 변경사항을 유지한다.
|
다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다.
|
||||||
이는 전체 오브젝트 구성을 대체하기 위해 `replace` API 작업을 이용하는 대신,
|
이것은 전체 오브젝트 구성 변경을 위한 `replace` API를
|
||||||
오직 인지된 차이점을 기록하기 위한 `patch`
|
사용하는 대신, `patch` API를 사용하여 인지되는 차이만
|
||||||
API 작업을 이용함으로서 가능하다.
|
작성하기 때문에 가능하다.
|
||||||
{{< /note >}}
|
{{< /note >}}
|
||||||
|
|
||||||
### 예시
|
### 예시
|
||||||
|
|
@ -163,24 +164,24 @@ kubectl apply -R -f configs/
|
||||||
|
|
||||||
### 트레이드 오프
|
### 트레이드 오프
|
||||||
|
|
||||||
명령형 오브젝트 구성과 비교한 장점은
|
명령형 오브젝트 구성에 비해 장점은 다음과 같다.
|
||||||
|
|
||||||
- 구성 파일로 되돌려 병합될 수 없기는 하지만, 활성 오브젝트에 직접 이루어진 변경사항이 유지된다.
|
- 활성 오브젝트에 직접 작성된 변경 사항은 구성 파일로 다시 병합되지 않더라도 유지된다.
|
||||||
- 선언형 오브젝트 구성은 디렉토리에 관한 동작에 대해 더 나은 지원을 하고 자동으로 오브젝트 마다의 작업(생성, 패치, 삭제)을 감지한다.
|
- 선언형 오브젝트 구성은 디렉토리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다.
|
||||||
|
|
||||||
명령형 오브젝트 구성과 비교한 단점은
|
명령형 오브젝트 구성에 비해 단점은 다음과 같다.
|
||||||
|
|
||||||
- 선언형 오브젝트 구성은 예측이 불가할 경우 디버그 하기가 더 어렵고 결과를 이해하기가 더 어렵다.
|
- 선언형 오브젝트 구성은 예상치 못한 결과를 디버깅하고 이해하기가 더 어렵다.
|
||||||
- 차이점를 이용한 부분적 업데이트는 복잡한 병합과 패치 작업을 만들어 낸다.
|
- diff를 사용한 부분 업데이트는 복잡한 병합 및 패치 작업을 일으킨다.
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
{{% capture whatsnext %}}
|
{{% capture whatsnext %}}
|
||||||
- [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
|
- [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
|
||||||
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
|
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
|
||||||
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||||
- [Kustomize를 사용한 쿠버네티스 오브젝트 관리하기 (선언형)](/docs/tasks/manage-kubernetes-objects/kustomization/)
|
- [Kustomize를 사용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)
|
||||||
- [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl-commands/)
|
- [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||||
- [Kubectl 서적](https://kubectl.docs.kubernetes.io)
|
- [Kubectl 서적](https://kubectl.docs.kubernetes.io)
|
||||||
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -152,7 +152,7 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 클라이
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
{{% capture whatsnext %}}
|
{{% capture whatsnext %}}
|
||||||
* [파드에 대한 네트워크 정책](/docs/concepts/services-networking/network-policies/) 알아보기
|
* [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/) 알아보기
|
||||||
* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)에 대해 알아보기
|
* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)에 대해 알아보기
|
||||||
* [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/)에 대해 알아보기
|
* [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/)에 대해 알아보기
|
||||||
* 컨트롤 플레인에 대한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) 알아보기
|
* 컨트롤 플레인에 대한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) 알아보기
|
||||||
|
|
|
||||||
|
|
@ -418,10 +418,8 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
|
||||||
|
|
||||||
{{% capture whatsnext %}}
|
{{% capture whatsnext %}}
|
||||||
|
|
||||||
게다가 쿠버네티스는 여러 클러스터와 클라우드 공급자들을 포괄하는
|
* [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다.
|
||||||
페더레이션 서비스를 지원하여 가용성을 높이고 내결함성을 향상시키며,
|
* [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다.
|
||||||
보다 큰 서비스의 확장성을 제공한다. 자세한 내용은
|
* [외부 로드 밸런서를 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다.
|
||||||
[페더레이션 서비스 사용자 가이드](/docs/concepts/cluster-administration/federation-service-discovery/)
|
|
||||||
를 본다.
|
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
|
||||||
|
|
@ -30,6 +30,8 @@ term_id="selector" >}} 가 지정되면 EndpointSlice
|
||||||
컨트롤러는 자동으로 엔드포인트슬라이스를 생성한다. 이 엔드포인트슬라이스는
|
컨트롤러는 자동으로 엔드포인트슬라이스를 생성한다. 이 엔드포인트슬라이스는
|
||||||
서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트슬라이스는
|
서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트슬라이스는
|
||||||
고유한 서비스와 포트 조합을 통해 네트워크 엔드포인트를 그룹화 한다.
|
고유한 서비스와 포트 조합을 통해 네트워크 엔드포인트를 그룹화 한다.
|
||||||
|
EndpointSlice 오브젝트의 이름은 유효한
|
||||||
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
|
||||||
|
|
||||||
예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 EndpointSlice
|
예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 EndpointSlice
|
||||||
리소스 샘플이 있다.
|
리소스 샘플이 있다.
|
||||||
|
|
|
||||||
|
|
@ -76,11 +76,13 @@ spec:
|
||||||
servicePort: 80
|
servicePort: 80
|
||||||
```
|
```
|
||||||
|
|
||||||
다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다.
|
다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다.
|
||||||
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
|
인그레스 오브젝트의 이름은 유효한
|
||||||
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
|
||||||
|
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
|
||||||
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
|
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
|
||||||
그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
|
그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
|
||||||
다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
|
다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
|
||||||
지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.
|
지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.
|
||||||
|
|
||||||
인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
|
인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
|
||||||
|
|
@ -132,10 +134,10 @@ kubectl get ingress test-ingress
|
||||||
|
|
||||||
```
|
```
|
||||||
NAME HOSTS ADDRESS PORTS AGE
|
NAME HOSTS ADDRESS PORTS AGE
|
||||||
test-ingress * 107.178.254.228 80 59s
|
test-ingress * 203.0.113.123 80 59s
|
||||||
```
|
```
|
||||||
|
|
||||||
여기서 `107.178.254.228` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해
|
여기서 `203.0.113.123` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해
|
||||||
할당한 IP 이다.
|
할당한 IP 이다.
|
||||||
|
|
||||||
{{< note >}}
|
{{< note >}}
|
||||||
|
|
|
||||||
|
|
@ -73,6 +73,8 @@ _서비스_ 로 들어가보자.
|
||||||
쿠버네티스의 서비스는 파드와 비슷한 REST 오브젝트이다. 모든 REST 오브젝트와
|
쿠버네티스의 서비스는 파드와 비슷한 REST 오브젝트이다. 모든 REST 오브젝트와
|
||||||
마찬가지로, 서비스 정의를 API 서버에 `POST`하여
|
마찬가지로, 서비스 정의를 API 서버에 `POST`하여
|
||||||
새 인스턴스를 생성할 수 있다.
|
새 인스턴스를 생성할 수 있다.
|
||||||
|
서비스 오브젝트의 이름은 유효한
|
||||||
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
|
||||||
|
|
||||||
예를 들어, 각각 TCP 포트 9376에서 수신하고
|
예를 들어, 각각 TCP 포트 9376에서 수신하고
|
||||||
`app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
|
`app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
|
||||||
|
|
@ -167,6 +169,9 @@ subsets:
|
||||||
- port: 9376
|
- port: 9376
|
||||||
```
|
```
|
||||||
|
|
||||||
|
엔드포인트 오브젝트의 이름은 유효한
|
||||||
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
|
||||||
|
|
||||||
{{< note >}}
|
{{< note >}}
|
||||||
엔드포인트 IP는 루프백(loopback) (IPv4의 경우 127.0.0.0/8, IPv6의 경우 ::1/128), 또는
|
엔드포인트 IP는 루프백(loopback) (IPv4의 경우 127.0.0.0/8, IPv6의 경우 ::1/128), 또는
|
||||||
링크-로컬 (IPv4의 경우 169.254.0.0/16와 224.0.0.0/24, IPv6의 경우 fe80::/64)이 _되어서는 안된다_.
|
링크-로컬 (IPv4의 경우 169.254.0.0/16와 224.0.0.0/24, IPv6의 경우 fe80::/64)이 _되어서는 안된다_.
|
||||||
|
|
@ -1172,19 +1177,6 @@ SCTP는 Windows 기반 노드를 지원하지 않는다.
|
||||||
kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다.
|
kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다.
|
||||||
{{< /warning >}}
|
{{< /warning >}}
|
||||||
|
|
||||||
## 향후 작업
|
|
||||||
|
|
||||||
향후, 서비스에 대한 프록시 정책은 예를 들어, 마스터-선택 또는 샤드 같은
|
|
||||||
단순한 라운드-로빈 밸런싱보다 미묘한 차이가 생길 수 있다. 또한
|
|
||||||
일부 서비스에는 "실제" 로드 밸런서가 있을 것으로 예상되는데, 이 경우
|
|
||||||
가상 IP 주소는 단순히 패킷을 그곳으로 전송한다.
|
|
||||||
|
|
||||||
쿠버네티스 프로젝트는 L7 (HTTP) 서비스에 대한 지원을 개선하려고 한다.
|
|
||||||
|
|
||||||
쿠버네티스 프로젝트는 현재 ClusterIP, NodePort 및 LoadBalancer 모드 등을 포함하는 서비스에 대해
|
|
||||||
보다 유연한 인그레스 모드를 지원하려고 한다.
|
|
||||||
|
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
{{% capture whatsnext %}}
|
{{% capture whatsnext %}}
|
||||||
|
|
|
||||||
|
|
@ -56,6 +56,10 @@ spec:
|
||||||
name: pvc-1
|
name: pvc-1
|
||||||
```
|
```
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
`spec.resources.requests.storage` 에 용량 값을 지정해야 하며, 지정한 값은 소스 볼륨의 용량과 같거나 또는 더 커야 한다.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
그 결과로 지정된 소스 `pvc-1` 과 동일한 내용을 가진 `clone-of-pvc-1` 이라는 이름을 가지는 새로운 PVC가 생겨난다.
|
그 결과로 지정된 소스 `pvc-1` 과 동일한 내용을 가진 `clone-of-pvc-1` 이라는 이름을 가지는 새로운 PVC가 생겨난다.
|
||||||
|
|
||||||
## 사용
|
## 사용
|
||||||
|
|
|
||||||
|
|
@ -599,6 +599,38 @@ spec:
|
||||||
type: Directory
|
type: Directory
|
||||||
```
|
```
|
||||||
|
|
||||||
|
{{< caution >}}
|
||||||
|
`FileOrCreate` 모드에서는 파일의 상위 디렉터리가 생성되지 않는다. 마운트된 파일의 상위 디렉터리가 없으면 파드가 시작되지 않는다. 이 모드가 작동하도록 하기 위해 다음과 같이 디렉터리와 파일을 별도로 마운트할 수 있다.
|
||||||
|
{{< /caution >}}
|
||||||
|
|
||||||
|
#### FileOrCreate 파드 예시
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: v1
|
||||||
|
kind: Pod
|
||||||
|
metadata:
|
||||||
|
name: test-webserver
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: test-webserver
|
||||||
|
image: k8s.gcr.io/test-webserver:latest
|
||||||
|
volumeMounts:
|
||||||
|
- mountPath: /var/local/aaa
|
||||||
|
name: mydir
|
||||||
|
- mountPath: /var/local/aaa/1.txt
|
||||||
|
name: myfile
|
||||||
|
volumes:
|
||||||
|
- name: mydir
|
||||||
|
hostPath:
|
||||||
|
# 파일 디렉터리가 생성되었는지 확인한다.
|
||||||
|
path: /var/local/aaa
|
||||||
|
type: DirectoryOrCreate
|
||||||
|
- name: myfile
|
||||||
|
hostPath:
|
||||||
|
path: /var/local/aaa/1.txt
|
||||||
|
type: FileOrCreate
|
||||||
|
```
|
||||||
|
|
||||||
### iscsi {#iscsi}
|
### iscsi {#iscsi}
|
||||||
|
|
||||||
`iscsi` 볼륨을 사용하면 기존 iSCSI (SCSI over IP) 볼륨을 파드에 마운트
|
`iscsi` 볼륨을 사용하면 기존 iSCSI (SCSI over IP) 볼륨을 파드에 마운트
|
||||||
|
|
@ -1440,5 +1472,5 @@ sudo systemctl restart docker
|
||||||
|
|
||||||
|
|
||||||
{{% capture whatsnext %}}
|
{{% capture whatsnext %}}
|
||||||
* [퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다.
|
* [퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다.
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,7 @@ weight: 80
|
||||||
|
|
||||||
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
|
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
|
||||||
|
|
||||||
_크론 잡은_ 시간 기반의 일정에 따라 [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 만든다.
|
_크론 잡은_ 시간 기반의 일정에 따라 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 만든다.
|
||||||
|
|
||||||
하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.
|
하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.
|
||||||
|
|
||||||
|
|
@ -23,7 +23,8 @@ _크론 잡은_ 시간 기반의 일정에 따라 [잡](/docs/concepts/workloads
|
||||||
{{< /caution >}}
|
{{< /caution >}}
|
||||||
|
|
||||||
크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이
|
크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이
|
||||||
52자 이하인지 확인해야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에
|
유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
|
||||||
|
이름은 52자 이하여야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에
|
||||||
11자를 자동으로 추가하고, 작업 이름의 최대 길이는
|
11자를 자동으로 추가하고, 작업 이름의 최대 길이는
|
||||||
63자라는 제약 조건이 있기 때문이다.
|
63자라는 제약 조건이 있기 때문이다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -33,7 +33,8 @@ YAML 파일로 데몬셋을 설명 할 수 있다. 예를 들어 아래 `daemons
|
||||||
|
|
||||||
{{< codenew file="controllers/daemonset.yaml" >}}
|
{{< codenew file="controllers/daemonset.yaml" >}}
|
||||||
|
|
||||||
* YAML 파일을 기반으로 데몬셋을 생성한다.
|
YAML 파일을 기반으로 데몬셋을 생성한다.
|
||||||
|
|
||||||
```
|
```
|
||||||
kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
||||||
```
|
```
|
||||||
|
|
@ -44,6 +45,8 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
||||||
일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/),
|
일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/),
|
||||||
[컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
|
[컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
|
||||||
|
|
||||||
|
데몬셋 오브젝트의 이름은 유효한
|
||||||
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
|
||||||
데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다.
|
데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다.
|
||||||
|
|
||||||
### 파드 템플릿
|
### 파드 템플릿
|
||||||
|
|
@ -61,7 +64,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
||||||
### 파드 셀렉터
|
### 파드 셀렉터
|
||||||
|
|
||||||
`.spec.selector` 필드는 파드 셀렉터이다. 이것은
|
`.spec.selector` 필드는 파드 셀렉터이다. 이것은
|
||||||
[잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)의 `.spec.selector` 와 같은 동작을 한다.
|
[잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)의 `.spec.selector` 와 같은 동작을 한다.
|
||||||
|
|
||||||
쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다.
|
쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다.
|
||||||
파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다.
|
파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다.
|
||||||
|
|
|
||||||
|
|
@ -1018,6 +1018,8 @@ $ echo $?
|
||||||
다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
|
다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
|
||||||
설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
|
설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
|
||||||
컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다.
|
컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다.
|
||||||
|
디플로이먼트 오브젝트의 이름은 유효한
|
||||||
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
|
||||||
|
|
||||||
디플로이먼트에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
|
디플로이먼트에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -36,7 +36,7 @@ weight: 70
|
||||||
이 명령으로 예시를 실행할 수 있다.
|
이 명령으로 예시를 실행할 수 있다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl apply -f https://k8s.io/examples/controllers/job.yaml
|
kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
|
||||||
```
|
```
|
||||||
```
|
```
|
||||||
job.batch/pi created
|
job.batch/pi created
|
||||||
|
|
@ -111,6 +111,7 @@ kubectl logs $pods
|
||||||
## 잡 사양 작성하기
|
## 잡 사양 작성하기
|
||||||
|
|
||||||
다른 쿠버네티스의 설정과 마찬가지로 잡에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
|
다른 쿠버네티스의 설정과 마찬가지로 잡에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
|
||||||
|
잡의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
|
||||||
|
|
||||||
잡에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
|
잡에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -54,22 +54,26 @@ kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
|
||||||
```
|
```
|
||||||
|
|
||||||
현재 배포된 레플리카셋을 확인할 수 있다.
|
현재 배포된 레플리카셋을 확인할 수 있다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl get rs
|
kubectl get rs
|
||||||
```
|
```
|
||||||
|
|
||||||
그리고 생성된 프런트엔드를 볼 수 있다.
|
그리고 생성된 프런트엔드를 볼 수 있다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
NAME DESIRED CURRENT READY AGE
|
NAME DESIRED CURRENT READY AGE
|
||||||
frontend 3 3 3 6s
|
frontend 3 3 3 6s
|
||||||
```
|
```
|
||||||
|
|
||||||
또한 레플리카셋의 상태를 확인할 수 있다.
|
또한 레플리카셋의 상태를 확인할 수 있다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl describe rs/frontend
|
kubectl describe rs/frontend
|
||||||
```
|
```
|
||||||
|
|
||||||
출력은 다음과 유사할 것이다.
|
출력은 다음과 유사할 것이다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
Name: frontend
|
Name: frontend
|
||||||
Namespace: default
|
Namespace: default
|
||||||
|
|
@ -99,11 +103,13 @@ Events:
|
||||||
```
|
```
|
||||||
|
|
||||||
마지막으로 파드가 올라왔는지 확인할 수 있다.
|
마지막으로 파드가 올라왔는지 확인할 수 있다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl get pods
|
kubectl get pods
|
||||||
```
|
```
|
||||||
|
|
||||||
다음과 유사한 파드 정보를 볼 수 있다.
|
다음과 유사한 파드 정보를 볼 수 있다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
NAME READY STATUS RESTARTS AGE
|
NAME READY STATUS RESTARTS AGE
|
||||||
frontend-b2zdv 1/1 Running 0 6m36s
|
frontend-b2zdv 1/1 Running 0 6m36s
|
||||||
|
|
@ -113,11 +119,13 @@ frontend-wtsmm 1/1 Running 0 6m36s
|
||||||
|
|
||||||
또한 파드들의 소유자 참조 정보가 해당 프런트엔드 레플리카셋으로 설정되어 있는지 확인할 수 있다.
|
또한 파드들의 소유자 참조 정보가 해당 프런트엔드 레플리카셋으로 설정되어 있는지 확인할 수 있다.
|
||||||
확인을 위해서는 실행 중인 파드 중 하나의 yaml을 확인한다.
|
확인을 위해서는 실행 중인 파드 중 하나의 yaml을 확인한다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl get pods frontend-b2zdv -o yaml
|
kubectl get pods frontend-b2zdv -o yaml
|
||||||
```
|
```
|
||||||
|
|
||||||
메타데이터의 ownerReferences 필드에 설정되어있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
|
메타데이터의 ownerReferences 필드에 설정되어있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: Pod
|
kind: Pod
|
||||||
|
|
@ -162,11 +170,13 @@ kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
|
||||||
즉시 종료된다.
|
즉시 종료된다.
|
||||||
|
|
||||||
파드를 가져온다.
|
파드를 가져온다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl get pods
|
kubectl get pods
|
||||||
```
|
```
|
||||||
|
|
||||||
결과에는 새로운 파드가 이미 종료되었거나 종료가 진행 중인 것을 보여준다.
|
결과에는 새로운 파드가 이미 종료되었거나 종료가 진행 중인 것을 보여준다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
NAME READY STATUS RESTARTS AGE
|
NAME READY STATUS RESTARTS AGE
|
||||||
frontend-b2zdv 1/1 Running 0 10m
|
frontend-b2zdv 1/1 Running 0 10m
|
||||||
|
|
@ -177,17 +187,20 @@ pod2 0/1 Terminating 0 1s
|
||||||
```
|
```
|
||||||
|
|
||||||
파드를 먼저 생성한다.
|
파드를 먼저 생성한다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
|
kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
|
||||||
```
|
```
|
||||||
|
|
||||||
그 다음 레플리카셋을 생성한다.
|
그 다음 레플리카셋을 생성한다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
|
kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
|
||||||
```
|
```
|
||||||
|
|
||||||
레플리카셋이 해당 파드를 소유한 것을 볼 수 있으며 새 파드 및 기존 파드의 수가
|
레플리카셋이 해당 파드를 소유한 것을 볼 수 있으며 새 파드 및 기존 파드의 수가
|
||||||
레플리카셋이 필요로 하는 수와 일치할 때까지 사양에 따라 신규 파드만 생성한다. 파드를 가져온다.
|
레플리카셋이 필요로 하는 수와 일치할 때까지 사양에 따라 신규 파드만 생성한다. 파드를 가져온다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl get pods
|
kubectl get pods
|
||||||
```
|
```
|
||||||
|
|
@ -209,6 +222,9 @@ pod2 1/1 Running 0 36s
|
||||||
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
|
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
|
||||||
API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
|
API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
|
||||||
|
|
||||||
|
레플리카셋 오브젝트의 이름은 유효한
|
||||||
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
|
||||||
|
|
||||||
레플리카셋도 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)이 필요하다.
|
레플리카셋도 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)이 필요하다.
|
||||||
|
|
||||||
### 파드 템플릿
|
### 파드 템플릿
|
||||||
|
|
|
||||||
|
|
@ -113,6 +113,8 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
|
||||||
## 레플리케이션 컨트롤러의 Spec 작성
|
## 레플리케이션 컨트롤러의 Spec 작성
|
||||||
|
|
||||||
다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
|
다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
|
||||||
|
레플리케이션 컨트롤러 오브젝트의 이름은 유효한
|
||||||
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
|
||||||
컨피그 파일의 동작에 관련된 일반적인 정보는 다음을 참조하라 [쿠버네티스 오브젝트 관리 ](/ko/docs/concepts/overview/working-with-objects/object-management/).
|
컨피그 파일의 동작에 관련된 일반적인 정보는 다음을 참조하라 [쿠버네티스 오브젝트 관리 ](/ko/docs/concepts/overview/working-with-objects/object-management/).
|
||||||
|
|
||||||
레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 도 필요하다.
|
레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 도 필요하다.
|
||||||
|
|
@ -254,7 +256,7 @@ API 오브젝트에 대한 더 자세한 것은
|
||||||
|
|
||||||
### 레플리카셋
|
### 레플리카셋
|
||||||
|
|
||||||
[`레플리카셋`](/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
|
[`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
|
||||||
이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
|
이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
|
||||||
사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카 셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
|
사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카 셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -100,11 +100,16 @@ spec:
|
||||||
* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
|
* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
|
||||||
* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
|
* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
|
||||||
* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
|
* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
|
||||||
|
스테이트풀셋 오브젝트의 이름은 유효한
|
||||||
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
|
||||||
|
|
||||||
|
|
||||||
## 파드 셀렉터
|
## 파드 셀렉터
|
||||||
|
|
||||||
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
|
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
|
||||||
|
|
||||||
## 파드 신원
|
## 파드 신원
|
||||||
|
|
||||||
스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 그리고
|
스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 그리고
|
||||||
안정적인 스토리지로 구성되는 고유한 신원을 가진다. 신원은
|
안정적인 스토리지로 구성되는 고유한 신원을 가진다. 신원은
|
||||||
파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다.
|
파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다.
|
||||||
|
|
|
||||||
|
|
@ -10,7 +10,7 @@ weight: 65
|
||||||
|
|
||||||
TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
|
TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
|
||||||
제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재
|
제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재
|
||||||
[잡(Job)](/docs/concepts/workloads/controllers/jobs-run-to-completion/)만
|
[잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)만
|
||||||
처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
|
처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
|
||||||
처리하도록 확장될 수 있다.
|
처리하도록 확장될 수 있다.
|
||||||
|
|
||||||
|
|
@ -28,7 +28,7 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
|
||||||
## TTL 컨트롤러
|
## TTL 컨트롤러
|
||||||
|
|
||||||
현재의 TTL 컨트롤러는 잡만 지원한다. 클러스터 운영자는
|
현재의 TTL 컨트롤러는 잡만 지원한다. 클러스터 운영자는
|
||||||
[예시](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
|
[예시](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리)
|
||||||
와 같이 `.spec.ttlSecondsAfterFinished` 필드를 명시하여
|
와 같이 `.spec.ttlSecondsAfterFinished` 필드를 명시하여
|
||||||
완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다.
|
완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다.
|
||||||
리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때),
|
리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때),
|
||||||
|
|
@ -79,7 +79,7 @@ TTL 컨트롤러는 쿠버네티스 리소스에
|
||||||
|
|
||||||
{{% capture whatsnext %}}
|
{{% capture whatsnext %}}
|
||||||
|
|
||||||
[자동으로 잡 정리](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
|
[자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리)
|
||||||
|
|
||||||
[디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
|
[디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -46,7 +46,7 @@ weight: 60
|
||||||
클러스터 관리자의 작업:
|
클러스터 관리자의 작업:
|
||||||
|
|
||||||
- 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/).
|
- 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/).
|
||||||
- 클러스터의 스케일 축소를 위한 노드 드레이닝([클러스터 오토스케일링](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)에 대해 알아보기).
|
- 클러스터의 스케일 축소를 위한 노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)에 대해 알아보기).
|
||||||
- 노드에 다른 무언가를 추가하기 위해 파드를 제거.
|
- 노드에 다른 무언가를 추가하기 위해 파드를 제거.
|
||||||
|
|
||||||
위 작업은 클러스터 관리자가 직접 수행하거나 자동화를 통해 수행하며,
|
위 작업은 클러스터 관리자가 직접 수행하거나 자동화를 통해 수행하며,
|
||||||
|
|
|
||||||
|
|
@ -243,7 +243,7 @@ status:
|
||||||
파드의 새로운 조건들은
|
파드의 새로운 조건들은
|
||||||
쿠버네티스의 [레이블 키 포멧](/ko/docs/concepts/overview/working-with-objects/labels/#구문과-캐릭터-셋)을 준수해야 한다.
|
쿠버네티스의 [레이블 키 포멧](/ko/docs/concepts/overview/working-with-objects/labels/#구문과-캐릭터-셋)을 준수해야 한다.
|
||||||
`kubectl patch` 명령어가 오브젝트 상태 패치(patching)를 아직 제공하지 않기 때문에,
|
`kubectl patch` 명령어가 오브젝트 상태 패치(patching)를 아직 제공하지 않기 때문에,
|
||||||
새로운 파드 조건들은 [KubeClient 라이브러리](/docs/reference/using-api/client-libraries/)를 통한 `PATCH` 액션을 통해서 주입되어야 한다.
|
새로운 파드 조건들은 [KubeClient 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 통한 `PATCH` 액션을 통해서 주입되어야 한다.
|
||||||
|
|
||||||
새로운 파드 조건들이 적용된 경우, 파드는 **오직**
|
새로운 파드 조건들이 적용된 경우, 파드는 **오직**
|
||||||
다음 두 문장이 모두 참일 때만 준비 상태로 평가된다.
|
다음 두 문장이 모두 참일 때만 준비 상태로 평가된다.
|
||||||
|
|
|
||||||
|
|
@ -165,8 +165,8 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
|
||||||
1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은 것(죽은)것으로 간주되는 파드가 업데이트 된다.
|
1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은 것(죽은)것으로 간주되는 파드가 업데이트 된다.
|
||||||
1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다.
|
1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다.
|
||||||
1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다.
|
1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다.
|
||||||
1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초) 연장해서 2번 단계를 실행한다.
|
1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초)를 1회 연장해서 2번 단계를 실행한다.
|
||||||
1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자.
|
1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자. 만약 `preStop` 훅을 완료하는 데 더 오랜 시간이 필요한 경우 `terminationGracePeriodSeconds` 를 수정해야 한다.
|
||||||
1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행중인 파드로 고려하지 않는다.
|
1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행중인 파드로 고려하지 않는다.
|
||||||
느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다.
|
느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다.
|
||||||
1. 유예 기간이 만료되면, 파드에서 실행중이던 모든 프로세스가 SIGKILL로 종료된다.
|
1. 유예 기간이 만료되면, 파드에서 실행중이던 모든 프로세스가 SIGKILL로 종료된다.
|
||||||
|
|
@ -200,6 +200,7 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
|
||||||
|
|
||||||
파드는 쿠버네티스 REST API에서 최상위 리소스이다. API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다:
|
파드는 쿠버네티스 REST API에서 최상위 리소스이다. API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다:
|
||||||
[파드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
|
[파드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
|
||||||
|
파드 오브젝트에 대한 매니페스트를 생성할때는 지정된 이름이 유효한
|
||||||
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)인지 확인해야 한다.
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
|
||||||
|
|
@ -36,14 +36,14 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
|
||||||
## 역할과 책임
|
## 역할과 책임
|
||||||
|
|
||||||
- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여시 [CLA에 서명](/docs/contribute/start#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다.
|
- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여시 [CLA에 서명](/docs/contribute/start#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다.
|
||||||
- 쿠버네티스 조직의 **맴버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 맴버십 기준은 [커뮤니티 맴버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다.
|
- 쿠버네티스 조직의 **멤버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 멤버십 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다.
|
||||||
- SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로
|
- SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로
|
||||||
문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에
|
문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에
|
||||||
의해 GitHub 리포지터리에 있는 GitHub
|
의해 GitHub 리포지터리에 있는 GitHub
|
||||||
그룹과 `OWNER` 파일에 추가되었다.
|
그룹과 `OWNER` 파일에 추가되었다.
|
||||||
- SIG Docs의 **승인자** 는 프로젝트에 대한 지속적인 헌신을 보여준
|
- SIG Docs의 **승인자** 는 프로젝트에 대한 지속적인 헌신을 보여준
|
||||||
좋은 맴버이다. 승인자는 쿠버네티스 조직을 대신해서
|
좋은 멤버이다. 승인자는 쿠버네티스 조직을 대신해서
|
||||||
풀 리퀘스트를 병합하고 컨텐츠를 게시할 수 있다.
|
풀 리퀘스트를 병합하고 컨텐츠를 게시할 수 있다.
|
||||||
또한 승인자는 더 큰 쿠버네티스 커뮤니티의 SIG Docs를 대표할 수 있다.
|
또한 승인자는 더 큰 쿠버네티스 커뮤니티의 SIG Docs를 대표할 수 있다.
|
||||||
릴리즈 조정과 같은 SIG Docs 승인자의 일부 의무에는
|
릴리즈 조정과 같은 SIG Docs 승인자의 일부 의무에는
|
||||||
상당한 시간 투입이 필요하다.
|
상당한 시간 투입이 필요하다.
|
||||||
|
|
@ -58,18 +58,18 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
|
||||||
- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선할 아이디어를 제시한다.
|
- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선할 아이디어를 제시한다.
|
||||||
- `/lgtm` Prow 명령 ("looks good to me" 의 줄임말)을 사용해서 병합을 위한 풀 리퀘스트의 변경을 추천한다.
|
- `/lgtm` Prow 명령 ("looks good to me" 의 줄임말)을 사용해서 병합을 위한 풀 리퀘스트의 변경을 추천한다.
|
||||||
{{< note >}}
|
{{< note >}}
|
||||||
만약 쿠버네티스 조직의 맴버가 아니라면, `/lgtm` 을 사용하는 것은 자동화된 시스템에 아무런 영향을 주지 않는다.
|
만약 쿠버네티스 조직의 멤버가 아니라면, `/lgtm` 을 사용하는 것은 자동화된 시스템에 아무런 영향을 주지 않는다.
|
||||||
{{< /note >}}
|
{{< /note >}}
|
||||||
|
|
||||||
[CLS에 서명](/docs/contribute/start#sign-the-cla) 후에 누구나 다음을 할 수 있다.
|
[CLA에 서명](/docs/contribute/start#sign-the-cla) 후에 누구나 다음을 할 수 있다.
|
||||||
- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다.
|
- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다.
|
||||||
|
|
||||||
## 맴버
|
## 멤버
|
||||||
|
|
||||||
맴버는 [맴버 기준](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족하는 쿠버네티스 프로젝트에 기여한 사람들이다. SIG Docs는 쿠버네티스 커뮤니티의 모든 맴버로부터 기여를 환경하며,
|
멤버는 [멤버 기준](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족하는 쿠버네티스 프로젝트에 기여한 사람들이다. SIG Docs는 쿠버네티스 커뮤니티의 모든 멤버로부터 기여를 환경하며,
|
||||||
기술적 정확성에 대한 다른 SIG 맴버들의 검토를 수시로 요청한다.
|
기술적 정확성에 대한 다른 SIG 멤버들의 검토를 수시로 요청한다.
|
||||||
|
|
||||||
쿠버네티스 조직의 모든 맴버는 다음 작업을 할 수 있다.
|
쿠버네티스 조직의 모든 멤버는 다음 작업을 할 수 있다.
|
||||||
|
|
||||||
- [모든 사람](#모든-사람) 하위에 나열된 모든 것
|
- [모든 사람](#모든-사람) 하위에 나열된 모든 것
|
||||||
- 풀 리퀘스트 코멘트에 `/lgtm` 을 사용해서 LGTM(looks good to me) 레이블을 붙일 수 있다.
|
- 풀 리퀘스트 코멘트에 `/lgtm` 을 사용해서 LGTM(looks good to me) 레이블을 붙일 수 있다.
|
||||||
|
|
@ -106,7 +106,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
|
||||||
해당 GitHub 이슈를 종료한다.
|
해당 GitHub 이슈를 종료한다.
|
||||||
축하한다, 이제 멤버가 되었다!
|
축하한다, 이제 멤버가 되었다!
|
||||||
|
|
||||||
만약 맴버십 요청이 받아들여지지 않으면,
|
만약 멤버십 요청이 받아들여지지 않으면,
|
||||||
멤버십 위원회에서 재지원 전에
|
멤버십 위원회에서 재지원 전에
|
||||||
필요한 정보나 단계를 알려준다.
|
필요한 정보나 단계를 알려준다.
|
||||||
|
|
||||||
|
|
@ -117,7 +117,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
|
||||||
GitHub 그룹의 멤버이다. 리뷰어는 문서 풀 리퀘스트를 리뷰하고 제안받은 변경에 대한 피드백을
|
GitHub 그룹의 멤버이다. 리뷰어는 문서 풀 리퀘스트를 리뷰하고 제안받은 변경에 대한 피드백을
|
||||||
제공한다. 리뷰어는 다음 작업을 수행할 수 있다.
|
제공한다. 리뷰어는 다음 작업을 수행할 수 있다.
|
||||||
|
|
||||||
- [모든 사람](#모든-사람)과 [맴버](#맴버)에 나열된 모든 것을 수행
|
- [모든 사람](#모든-사람)과 [멤버](#멤버)에 나열된 모든 것을 수행
|
||||||
- 새 기능의 문서화
|
- 새 기능의 문서화
|
||||||
- 이슈 해결 및 분류
|
- 이슈 해결 및 분류
|
||||||
- 풀 리퀘스트 리뷰와 구속력있는 피드백 제공
|
- 풀 리퀘스트 리뷰와 구속력있는 피드백 제공
|
||||||
|
|
@ -171,7 +171,7 @@ GitHub 그룹의 멤버이다. [SIG Docs 팀과 자동화](#sig-docs-팀과-자
|
||||||
|
|
||||||
승인자는 다음의 작업을 할 수 있다.
|
승인자는 다음의 작업을 할 수 있다.
|
||||||
|
|
||||||
- [모든 사람](#모든-사람), [맴버](#맴버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다.
|
- [모든 사람](#모든-사람), [멤버](#멤버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다.
|
||||||
- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다.
|
- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다.
|
||||||
만약 승인자가 아닌 사람이 코멘트에 승인을 남기면 자동화 시스템에서 이를 무시한다.
|
만약 승인자가 아닌 사람이 코멘트에 승인을 남기면 자동화 시스템에서 이를 무시한다.
|
||||||
- 쿠버네티스 릴리즈팀에 문서 담당자로 참여
|
- 쿠버네티스 릴리즈팀에 문서 담당자로 참여
|
||||||
|
|
@ -292,10 +292,10 @@ PR 소유자에게 조언하는데 활용된다.
|
||||||
|
|
||||||
- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고,
|
- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고,
|
||||||
모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다.
|
모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다.
|
||||||
- 쿠버네티스 조직의 맴버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의
|
- 쿠버네티스 조직의 멤버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의
|
||||||
자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는
|
자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는
|
||||||
`/lgtm` 코멘트 보류).
|
`/lgtm` 코멘트 보류).
|
||||||
- 모든 쿠버네티스 맴버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다.
|
- 모든 쿠버네티스 멤버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다.
|
||||||
- SIG Docs 승인자들만이 코멘트에 `/approve` 를
|
- SIG Docs 승인자들만이 코멘트에 `/approve` 를
|
||||||
추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은
|
추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은
|
||||||
[PR Wrangler](#pr-wrangler) 또는 [SIG Docs 의장](#sig-docs-의장)과
|
[PR Wrangler](#pr-wrangler) 또는 [SIG Docs 의장](#sig-docs-의장)과
|
||||||
|
|
|
||||||
|
|
@ -14,6 +14,8 @@ menu:
|
||||||
weight: 20
|
weight: 20
|
||||||
post: >
|
post: >
|
||||||
<p>개념, 튜토리얼 및 참조 문서와 함께 쿠버네티스 사용하는 방법을 익힐 수 있다. 또한, <a href="/editdocs/" data-auto-burger-exclude>문서에 기여하는 것도 도움을 줄 수 있다</a>!</p>
|
<p>개념, 튜토리얼 및 참조 문서와 함께 쿠버네티스 사용하는 방법을 익힐 수 있다. 또한, <a href="/editdocs/" data-auto-burger-exclude>문서에 기여하는 것도 도움을 줄 수 있다</a>!</p>
|
||||||
|
description: >
|
||||||
|
쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하기 위한 오픈소스 컨테이너 오케스트레이션 엔진이다. 오픈소스 프로젝트는 Cloud Native Computing Foundation에서 주관한다.
|
||||||
overview: >
|
overview: >
|
||||||
쿠버네티스는 배포, 스케일링, 그리고 컨테이너화된 애플리케이션의 관리를 자동화 해주는 오픈 소스 컨테이너 오케스트레이션 엔진이다. 본 오픈 소스 프로젝트는 Cloud Native Computing Foundation(<a href="https://www.cncf.io/about">CNCF</a>)가 주관한다.
|
쿠버네티스는 배포, 스케일링, 그리고 컨테이너화된 애플리케이션의 관리를 자동화 해주는 오픈 소스 컨테이너 오케스트레이션 엔진이다. 본 오픈 소스 프로젝트는 Cloud Native Computing Foundation(<a href="https://www.cncf.io/about">CNCF</a>)가 주관한다.
|
||||||
cards:
|
cards:
|
||||||
|
|
@ -37,6 +39,11 @@ cards:
|
||||||
description: "일반적인 태스크와 이를 수행하는 방법을 여러 단계로 구성된 짧은 시퀀스를 통해 살펴본다."
|
description: "일반적인 태스크와 이를 수행하는 방법을 여러 단계로 구성된 짧은 시퀀스를 통해 살펴본다."
|
||||||
button: "태스크 보기"
|
button: "태스크 보기"
|
||||||
button_path: "/ko/docs/tasks"
|
button_path: "/ko/docs/tasks"
|
||||||
|
- name: training
|
||||||
|
title: 교육"
|
||||||
|
description: "공인 쿠버네티스 인증을 획득하고 클라우드 네이티브 프로젝트를 성공적으로 수행하세요!"
|
||||||
|
button: "교육 보기"
|
||||||
|
button_path: "/training"
|
||||||
- name: reference
|
- name: reference
|
||||||
title: 레퍼런스 정보 찾기
|
title: 레퍼런스 정보 찾기
|
||||||
description: 용어, 커맨드 라인 구문, API 자원 종류, 그리고 설치 툴 문서를 살펴본다.
|
description: 용어, 커맨드 라인 구문, API 자원 종류, 그리고 설치 툴 문서를 살펴본다.
|
||||||
|
|
|
||||||
|
|
@ -22,7 +22,7 @@ content_template: templates/concept
|
||||||
## API 클라이언트 라이브러리
|
## API 클라이언트 라이브러리
|
||||||
|
|
||||||
프로그래밍 언어에서 쿠버네티스 API를 호출하기 위해서,
|
프로그래밍 언어에서 쿠버네티스 API를 호출하기 위해서,
|
||||||
[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)를 사용할 수 있다.
|
[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용할 수 있다.
|
||||||
공식적으로 지원되는 클라이언트 라이브러리는 다음과 같다.
|
공식적으로 지원되는 클라이언트 라이브러리는 다음과 같다.
|
||||||
|
|
||||||
- [쿠버네티스 Go 클라이언트 라이브러리](https://github.com/kubernetes/client-go/)
|
- [쿠버네티스 Go 클라이언트 라이브러리](https://github.com/kubernetes/client-go/)
|
||||||
|
|
|
||||||
|
|
@ -14,5 +14,5 @@ tags:
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
어노테이션으로 된 메타데이터는 작거나 클 수 있고, 구조화되어 있거나 구조화되어 있지 않을 수도 있고, 레이블에서는 허용되지 않는 문자도 포함할 수 있다. 툴과 라이브러리와 같은 클라이언트로 메타데이터를 검색할 수 있다.
|
어노테이션으로 된 메타데이터는 작거나 클 수 있고, 구조화되어 있거나 구조화되어 있지 않을 수도 있고, {{< glossary_tooltip text="레이블" term_id="label" >}}에서는 허용되지 않는 문자도 포함할 수 있다. 툴과 라이브러리와 같은 클라이언트로 메타데이터를 검색할 수 있다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -4,7 +4,7 @@ id: cluster
|
||||||
date: 2019-06-15
|
date: 2019-06-15
|
||||||
full_link:
|
full_link:
|
||||||
short_description: >
|
short_description: >
|
||||||
컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다.
|
컨테이너화된 애플리케이션을 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다.
|
||||||
|
|
||||||
aka:
|
aka:
|
||||||
tags:
|
tags:
|
||||||
|
|
@ -14,4 +14,9 @@ tags:
|
||||||
컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다.
|
컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다.
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
워커 노드는 애플리케이션의 구성요소인 파드를 호스트한다. 컨트롤 플레인은 워커 노드와 클러스터 내 파드를 관리한다. 프로덕션 환경에서는 일반적으로 컨트롤 플레인이 여러 컴퓨터에 걸쳐 실행되고, 클러스터는 일반적으로 여러 노드를 실행하므로 내결함성과 고가용성이 제공된다.
|
워커 노드는 애플리케이션의 구성요소인
|
||||||
|
{{< glossary_tooltip text="파드" term_id="pod" >}}를 호스트한다.
|
||||||
|
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 워커 노드와
|
||||||
|
클러스터 내 파드를 관리한다. 프로덕션 환경에서는 일반적으로 컨트롤 플레인이
|
||||||
|
여러 컴퓨터에 걸쳐 실행되고, 클러스터는 일반적으로 여러 노드를
|
||||||
|
실행하므로 내결함성과 고가용성이 제공된다.
|
||||||
|
|
|
||||||
|
|
@ -10,7 +10,7 @@ aka:
|
||||||
tags:
|
tags:
|
||||||
- fundamental
|
- fundamental
|
||||||
---
|
---
|
||||||
컨테이너 환경 변수는 파드에서 동작 중인 컨테이너에 유용한 정보를 제공하기 위한 이름=값 쌍이다.
|
컨테이너 환경 변수는 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 동작 중인 컨테이너에 유용한 정보를 제공하기 위한 이름=값 쌍이다.
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -4,14 +4,14 @@ id: cronjob
|
||||||
date: 2018-04-12
|
date: 2018-04-12
|
||||||
full_link: /ko/docs/concepts/workloads/controllers/cron-jobs/
|
full_link: /ko/docs/concepts/workloads/controllers/cron-jobs/
|
||||||
short_description: >
|
short_description: >
|
||||||
주기적인 일정에 따라 실행되는 [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리.
|
주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리.
|
||||||
|
|
||||||
aka:
|
aka:
|
||||||
tags:
|
tags:
|
||||||
- core-object
|
- core-object
|
||||||
- workload
|
- workload
|
||||||
---
|
---
|
||||||
주기적인 일정에 따라 실행되는 [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리.
|
주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리.
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -16,5 +16,5 @@ tags:
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, 파드는 클러스터의 노드에 분산된다.
|
각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, 파드는 클러스터의 {{< glossary_tooltip text="노드" term_id="node" >}}에 분산된다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -10,7 +10,7 @@ aka:
|
||||||
tags:
|
tags:
|
||||||
- fundamental
|
- fundamental
|
||||||
---
|
---
|
||||||
컨테이너의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다.
|
{{< glossary_tooltip term_id="container" >}}의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다.
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -10,9 +10,8 @@ aka:
|
||||||
tags:
|
tags:
|
||||||
- fundamental
|
- fundamental
|
||||||
---
|
---
|
||||||
앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너.
|
앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 {{< glossary_tooltip text="컨테이너" term_id="container" >}}.
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
한 가지 차이점을 제외하면, 초기화 컨테이너는 일반적인 앱 컨테이너와 동일하다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 완료되는 것을 목표로 실행되어야 한다. 초기화 컨테이너는 연달아 실행된다. 다시말해, 각 초기화 컨테이너의 실행은 다음 초기화 컨테이너가 시작되기 전에 완료되어야 한다.
|
한 가지 차이점을 제외하면, 초기화 컨테이너는 일반적인 앱 컨테이너와 동일하다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 완료되는 것을 목표로 실행되어야 한다. 초기화 컨테이너는 연달아 실행된다. 다시말해, 각 초기화 컨테이너의 실행은 다음 초기화 컨테이너가 시작되기 전에 완료되어야 한다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -11,10 +11,16 @@ tags:
|
||||||
- fundamental
|
- fundamental
|
||||||
- networking
|
- networking
|
||||||
---
|
---
|
||||||
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 {{< glossary_tooltip text="서비스" term_id="service">}} 개념의 구현부이다.
|
kube-proxy는 클러스터의 각
|
||||||
|
{{< glossary_tooltip text="노드" term_id="node" >}}에서
|
||||||
|
실행되는 네트워크 프록시로, 쿠버네티스의
|
||||||
|
{{< glossary_tooltip text="서비스" term_id="service">}} 개념의 구현부이다.
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.
|
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)는
|
||||||
|
노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크
|
||||||
|
세션이나 클러스터 바깥에서 파드로 네트워크 통신을
|
||||||
|
할 수 있도록 해준다.
|
||||||
|
|
||||||
kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.
|
kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.
|
||||||
|
|
|
||||||
|
|
@ -10,9 +10,15 @@ aka:
|
||||||
tags:
|
tags:
|
||||||
- architecture
|
- architecture
|
||||||
---
|
---
|
||||||
노드가 배정되지 않은 새로 생성된 파드를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트.
|
{{< glossary_tooltip term_id="node" text="노드" >}}가 배정되지 않은 새로 생성된
|
||||||
|
{{< glossary_tooltip term_id="pod" text="파드" >}} 를 감지하고,
|
||||||
|
실행할 노드를 선택하는 컨트롤
|
||||||
|
플레인 컴포넌트.
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함한다.
|
스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한
|
||||||
|
개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약,
|
||||||
|
어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세,
|
||||||
|
데이터 지역성, 워크로드-간 간섭, 데드라인을 포함한다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -11,7 +11,7 @@ tags:
|
||||||
- fundamental
|
- fundamental
|
||||||
- core-object
|
- core-object
|
||||||
---
|
---
|
||||||
클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.
|
클러스터의 각 {{< glossary_tooltip text="노드" term_id="node" >}}에서 실행되는 에이전트. Kubelet은 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 {{< glossary_tooltip text="컨테이너" term_id="container" >}}가 확실하게 동작하도록 관리한다.
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -11,7 +11,7 @@ tags:
|
||||||
- workload
|
- workload
|
||||||
- core-object
|
- core-object
|
||||||
---
|
---
|
||||||
특정 수의 파드 인스턴스가 항상 동작하도록 보장하는 쿠버네티스 서비스.
|
특정 수의 {{< glossary_tooltip text="파드" term_id="pod" >}} 인스턴스가 항상 동작하도록 보장하는 쿠버네티스 서비스.
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -10,9 +10,8 @@ aka:
|
||||||
tags:
|
tags:
|
||||||
- fundamental
|
- fundamental
|
||||||
---
|
---
|
||||||
사용자가 레이블에 따라서 리소스 리스트를 필터할 수 있게 한다.
|
사용자가 {{< glossary_tooltip text="레이블" term_id="label" >}}에 따라서 리소스 리스트를 필터할 수 있게 한다.
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
셀렉터는 리소스 리스트를 질의할 때 리스트를 {{< glossary_tooltip text="레이블" term_id="label" >}}에 따라서 필터하기 위해서 적용된다.Selectors are applied when querying lists of resources to filter them by {{< glossary_tooltip text="Labels" term_id="label" >}}.
|
셀렉터는 리소스 리스트를 질의할 때 리스트를 레이블에 따라서 필터하기 위해서 적용된다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -11,8 +11,8 @@ tags:
|
||||||
- core-object
|
- core-object
|
||||||
- fundamental
|
- fundamental
|
||||||
---
|
---
|
||||||
세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지한다.
|
세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 {{< glossary_tooltip text="파드" term_id="pod" >}}가 {{< glossary_tooltip text="노드" term_id="node" >}}나 노드 그룹에 스케줄링되는 것을 방지한다.
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
테인트 및 {{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}은 함께 작동하며, 파드가 적절하지 못한 노드에 스케줄되는 것을 방지한다. 하나 이상의 테인트가 {{< glossary_tooltip text="노드" term_id="node" >}}에 적용될 수 있으며, 이것은 노드에 해당 테인트를 극복(tolerate)하지 않은 파드를 허용하지 않도록 표시한다.
|
테인트 및 {{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}은 함께 작동하며, 파드가 적절하지 못한 노드에 스케줄되는 것을 방지한다. 하나 이상의 테인트가 노드에 적용될 수 있으며, 이것은 노드에 해당 테인트를 극복(tolerate)하지 않은 파드를 허용하지 않도록 표시한다.
|
||||||
|
|
|
||||||
|
|
@ -11,9 +11,11 @@ tags:
|
||||||
- core-object
|
- core-object
|
||||||
- fundamental
|
- fundamental
|
||||||
---
|
---
|
||||||
데이터를 포함하고 있는 디렉토리이며, {{< glossary_tooltip text="파드" term_id="pod" >}}의 컨테이너에서 접근 가능하다.
|
데이터를 포함하고 있는 디렉토리이며, {{< glossary_tooltip term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다.
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
쿠버네티스 볼륨은 그것을 포함하고 있는 {{< glossary_tooltip text="파드" term_id="pod" >}}만큼 오래 산다. 결과적으로, 볼륨은 {{< glossary_tooltip text="파드" term_id="pod" >}} 안에서 실행되는 모든 {{< glossary_tooltip text="컨테이너" term_id="container" >}} 보다 오래 지속되며, 데이터는 {{< glossary_tooltip text="컨테이너" term_id="container" >}}의 재시작 간에도 보존된다.
|
쿠버네티스 볼륨은 그것을 포함하고 있는 파드만큼 오래 산다. 결과적으로, 볼륨은 파드 안에서 실행되는 모든 컨테이너 보다 오래 지속되며, 데이터는 컨테이너의 재시작 간에도 보존된다.
|
||||||
|
|
||||||
|
더 많은 정보는 [스토리지](https://kubernetes.io/ko/docs/concepts/storage/)를 본다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -38,13 +38,13 @@ complete -F __start_kubectl k
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
source <(kubectl completion zsh) # 현재 셸에 zsh의 자동 완성 설정
|
source <(kubectl completion zsh) # 현재 셸에 zsh의 자동 완성 설정
|
||||||
echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다.
|
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다.
|
||||||
```
|
```
|
||||||
|
|
||||||
## Kubectl 컨텍스트와 설정
|
## Kubectl 컨텍스트와 설정
|
||||||
|
|
||||||
`kubectl`이 통신하고 설정 정보를 수정하는 쿠버네티스 클러스터를
|
`kubectl`이 통신하고 설정 정보를 수정하는 쿠버네티스 클러스터를
|
||||||
지정한다. 설정 파일에 대한 자세한 정보는 [kubeconfig를 이용한 클러스터 간 인증](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 문서를
|
지정한다. 설정 파일에 대한 자세한 정보는 [kubeconfig를 이용한 클러스터 간 인증](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 문서를
|
||||||
참고한다.
|
참고한다.
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
|
|
@ -91,7 +91,7 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml # 여러 파일로 부터 생성
|
||||||
kubectl apply -f ./dir # dir 내 모든 매니페스트 파일에서 리소스(들) 생성
|
kubectl apply -f ./dir # dir 내 모든 매니페스트 파일에서 리소스(들) 생성
|
||||||
kubectl apply -f https://git.io/vPieo # url로부터 리소스(들) 생성
|
kubectl apply -f https://git.io/vPieo # url로부터 리소스(들) 생성
|
||||||
kubectl create deployment nginx --image=nginx # nginx 단일 인스턴스를 시작
|
kubectl create deployment nginx --image=nginx # nginx 단일 인스턴스를 시작
|
||||||
kubectl explain pods,svc # 파드와 서비스 매니페스트 문서를 조회
|
kubectl explain pods # 파드 매니페스트 문서를 조회
|
||||||
|
|
||||||
# stdin으로 다수의 YAML 오브젝트 생성
|
# stdin으로 다수의 YAML 오브젝트 생성
|
||||||
cat <<EOF | kubectl apply -f -
|
cat <<EOF | kubectl apply -f -
|
||||||
|
|
@ -144,7 +144,6 @@ kubectl get pods -o wide # 해당하는 네임스페이스
|
||||||
kubectl get deployment my-dep # 특정 디플로이먼트의 목록 조회
|
kubectl get deployment my-dep # 특정 디플로이먼트의 목록 조회
|
||||||
kubectl get pods # 네임스페이스 내 모든 파드의 목록 조회
|
kubectl get pods # 네임스페이스 내 모든 파드의 목록 조회
|
||||||
kubectl get pod my-pod -o yaml # 파드의 YAML 조회
|
kubectl get pod my-pod -o yaml # 파드의 YAML 조회
|
||||||
kubectl get pod my-pod -o yaml --export # 클러스터 명세 없이 파드의 YAML 조회
|
|
||||||
|
|
||||||
# 상세 출력을 위한 Describe 커맨드
|
# 상세 출력을 위한 Describe 커맨드
|
||||||
kubectl describe nodes my-node
|
kubectl describe nodes my-node
|
||||||
|
|
@ -188,6 +187,10 @@ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.ty
|
||||||
# 파드에 의해 현재 사용되고 있는 모든 시크릿 목록 조회
|
# 파드에 의해 현재 사용되고 있는 모든 시크릿 목록 조회
|
||||||
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
|
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
|
||||||
|
|
||||||
|
# 모든 파드의 초기화 컨테이너(initContainer)의 컨테이너ID 목록 조회
|
||||||
|
# 초기화 컨테이너(initContainer)를 제거하지 않고 정지된 모든 컨테이너를 정리할 때 유용하다.
|
||||||
|
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
|
||||||
|
|
||||||
# 타임스탬프로 정렬된 이벤트 목록 조회
|
# 타임스탬프로 정렬된 이벤트 목록 조회
|
||||||
kubectl get events --sort-by=.metadata.creationTimestamp
|
kubectl get events --sort-by=.metadata.creationTimestamp
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -31,7 +31,7 @@ content_template: templates/concept
|
||||||
|
|
||||||
## 대시보드
|
## 대시보드
|
||||||
|
|
||||||
[`대시보드`](/docs/tasks/access-application-cluster/web-ui-dashboard/), 는 쿠버네티스의 웹기반 유저 인터페이스이며 컨테이너화된 애플리케이션을 쿠버네티스 클러스터로 배포하고
|
[`대시보드`](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/), 는 쿠버네티스의 웹기반 유저 인터페이스이며 컨테이너화된 애플리케이션을 쿠버네티스 클러스터로 배포하고
|
||||||
클러스터 및 클러스터 자원의 문제를 해결하며 관리할 수 있게 해준다.
|
클러스터 및 클러스터 자원의 문제를 해결하며 관리할 수 있게 해준다.
|
||||||
|
|
||||||
## Helm
|
## Helm
|
||||||
|
|
|
||||||
|
|
@ -23,7 +23,7 @@ API 오브젝트로 취급되고,
|
||||||
그러나, REST 호출 사용을 통해서 API에 직접 접근할 수도 있다.
|
그러나, REST 호출 사용을 통해서 API에 직접 접근할 수도 있다.
|
||||||
|
|
||||||
쿠버네티스 API를 사용하는 애플리케이션을 작성하는 경우
|
쿠버네티스 API를 사용하는 애플리케이션을 작성하는 경우
|
||||||
[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)중 하나의 사용을 고려한다.
|
[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)중 하나의 사용을 고려한다.
|
||||||
|
|
||||||
## API 버전 규칙
|
## API 버전 규칙
|
||||||
|
|
||||||
|
|
@ -87,12 +87,14 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
|
||||||
- 쿠버네티스 API의 의미론적 전체 집합으로 사용자만의 Apiserver를 구현하려는 경우에는 [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
|
- 쿠버네티스 API의 의미론적 전체 집합으로 사용자만의 Apiserver를 구현하려는 경우에는 [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
|
||||||
|
|
||||||
|
|
||||||
## API 그룹 활성화 시키기
|
## API 그룹 활성화 또는 비활성화 하기
|
||||||
|
|
||||||
특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나
|
특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나
|
||||||
비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어:
|
비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어:
|
||||||
|
|
||||||
- batch/v1을 비활성화하려면 `--runtime-config=batch/v1=false`로 설정
|
- batch/v1을 비활성화하려면 `--runtime-config=batch/v1=false`로 설정
|
||||||
- batch/v2alpha1을 활성화하려면 `--runtime-config=batch/v2alpha1`로 설정
|
- batch/v2alpha1을 활성화하려면 `--runtime-config=batch/v2alpha1`로 설정
|
||||||
|
|
||||||
이 플래그는 apiserver의 런타임 구성을 설명하는 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
|
이 플래그는 apiserver의 런타임 구성을 설명하는 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
|
||||||
|
|
||||||
{{< note >}}
|
{{< note >}}
|
||||||
|
|
@ -100,12 +102,13 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
|
||||||
`--runtime-config` 변경을 반영해야 한다.
|
`--runtime-config` 변경을 반영해야 한다.
|
||||||
{{< /note >}}
|
{{< /note >}}
|
||||||
|
|
||||||
## 그룹 내 리소스 활성화 시키기
|
## extensions/v1beta1 그룹 내 특정 리소스 활성화 하기
|
||||||
|
|
||||||
데몬셋, 디플로이먼트, HorizontalPodAutoscaler, 인그레스, 잡 및 레플리카셋이 기본적으로 활성화되어 있다.
|
데몬셋, 디플로이먼트, 스테이트풀셋, 네트워크정책, 파드보안정책 그리고 레플리카셋은 `extensions/v1beta1` API 그룹에서 기본적으로 비활성화되어있다.
|
||||||
다른 확장 리소스는 apiserver의 `--runtime-config`를 설정해서
|
예시: 디플로이먼트와 데몬셋의 활성화 설정은
|
||||||
활성화할 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어 디플로이먼트와 잡을 비활성화하려면,
|
`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true` 를 입력한다.
|
||||||
`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`와 같이 설정한다.
|
|
||||||
|
{{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}}
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -58,6 +58,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery
|
||||||
| PHP | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) |
|
| PHP | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) |
|
||||||
| PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
|
| PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
|
||||||
| Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
|
| Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
|
||||||
|
| Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
|
||||||
| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
|
| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
|
||||||
| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
|
| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
|
||||||
| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
|
| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
|
||||||
|
|
|
||||||
|
|
@ -72,7 +72,7 @@ card:
|
||||||
| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔|
|
| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔|
|
||||||
| [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔
|
| [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔
|
||||||
| [Containership](https://containership.io) | ✔ |✔ | | | |
|
| [Containership](https://containership.io) | ✔ |✔ | | | |
|
||||||
| [D2iQ](https://d2iq.com/) | | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) |
|
| [D2iQ](https://d2iq.com/) | | [Kommander](https://docs.d2iq.com/ksphere/kommander/) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) |
|
||||||
| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔
|
| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔
|
||||||
| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | |
|
| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | |
|
||||||
| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔
|
| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔
|
||||||
|
|
@ -84,7 +84,7 @@ card:
|
||||||
| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
|
| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
|
||||||
| [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | |
|
| [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | |
|
||||||
| [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ |
|
| [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||||
| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | |
|
| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||||
| [KubeSail](https://kubesail.com/) | ✔ | | | | |
|
| [KubeSail](https://kubesail.com/) | ✔ | | | | |
|
||||||
| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ |
|
| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ |
|
||||||
| [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ |
|
| [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ |
|
||||||
|
|
|
||||||
|
|
@ -184,7 +184,7 @@ kubernetes-minion-wf8i Ready <none> 2m v1.13.0
|
||||||
|
|
||||||
Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
|
Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
|
||||||
|
|
||||||
```json
|
```bash
|
||||||
kubectl apply -f - <<EOF
|
kubectl apply -f - <<EOF
|
||||||
{
|
{
|
||||||
"apiVersion": "v1",
|
"apiVersion": "v1",
|
||||||
|
|
|
||||||
|
|
@ -20,7 +20,7 @@ Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다.
|
||||||
* 노드 포트
|
* 노드 포트
|
||||||
* 컨피그 맵과 시크릿
|
* 컨피그 맵과 시크릿
|
||||||
* 대시보드
|
* 대시보드
|
||||||
* 컨테이너 런타임: Docker, [CRI-O](https://cri-o.io/) 와 [containerd](https://github.com/containerd/containerd)
|
* 컨테이너 런타임: [Docker](https://www.docker.com/), [CRI-O](https://cri-o.io/) 와 [containerd](https://github.com/containerd/containerd)
|
||||||
* CNI(Container Network Interface) 사용
|
* CNI(Container Network Interface) 사용
|
||||||
* 인그레스
|
* 인그레스
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -50,14 +50,12 @@ curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://
|
||||||
| grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64
|
| grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64
|
||||||
```
|
```
|
||||||
|
|
||||||
특정 버전을 다운로드 받는다면 다음을 변경한다.
|
특정 버전을 다운로드 받는다면 명령의 다음부분을 특정 kops 버전으로 변경한다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
|
$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
|
||||||
```
|
```
|
||||||
|
|
||||||
특정 버전의 명령 부분이다.
|
|
||||||
|
|
||||||
예를 들어 kops 버전을 v1.15.0을 다운로드 하려면 다음을 입력한다.
|
예를 들어 kops 버전을 v1.15.0을 다운로드 하려면 다음을 입력한다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
|
|
|
||||||
|
|
@ -104,6 +104,14 @@ spec:
|
||||||
윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. 윈도우 파드만 서비스 IP 주소로 접근할 수 있다.
|
윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. 윈도우 파드만 서비스 IP 주소로 접근할 수 있다.
|
||||||
{{< /note >}}
|
{{< /note >}}
|
||||||
|
|
||||||
|
## 가시성
|
||||||
|
|
||||||
|
### 워크로드에서 로그 캡쳐하기
|
||||||
|
|
||||||
|
로그는 가시성의 중요한 요소이다. 로그는 사용자가 워크로드의 운영측면을 파악할 수 있도록 하며 문제 해결의 핵심 요소이다. 윈도우 컨테이너와 워크로드 내의 윈도우 컨테이너가 리눅스 컨테이너와는 다르게 동작하기 때문에, 사용자가 로그를 수집하는 데 어려움을 겪었기에 운영 가시성이 제한되었다. 예를 들어 윈도우 워크로드는 일반적으로 ETW(Event Tracing for Windows)에 로그인하거나 애플리케이션 이벤트 로그에 항목을 푸시하도록 구성한다. Microsoft의 오픈 소스 도구인 [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)는 윈도우 컨테이너 안에 구성된 로그 소스를 모니터링하는 권장하는 방법이다. LogMonitor는 이벤트 로그, ETW 공급자 그리고 사용자 정의 애플리케이션 로그 모니터링을 지원하고 `kubectl logs <pod>` 에 의한 사용을 위해 STDOUT으로 파이프한다.
|
||||||
|
|
||||||
|
LogMonitor Github 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고, LogMonitor에 필요한 입력 지점을 추가해서 로그를 STDOUT으로 푸시한다.
|
||||||
|
|
||||||
## 설정 가능한 컨테이너 username 사용하기
|
## 설정 가능한 컨테이너 username 사용하기
|
||||||
|
|
||||||
쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를 실행하도록 설정할 수 있다. 이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다. [여기](/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다.
|
쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를 실행하도록 설정할 수 있다. 이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다. [여기](/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다.
|
||||||
|
|
|
||||||
|
|
@ -291,7 +291,7 @@ v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes
|
||||||
|
|
||||||
본 단계는 다음의 행위를 수행한다.
|
본 단계는 다음의 행위를 수행한다.
|
||||||
|
|
||||||
1. 컨트롤 플레인("마스터") 노드에 SSH로 접속해서 [Kubeconfig 파일](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 얻어온다.
|
1. 컨트롤 플레인("마스터") 노드에 SSH로 접속해서 [Kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 얻어온다.
|
||||||
1. kubelet을 윈도우 서비스로 등록한다.
|
1. kubelet을 윈도우 서비스로 등록한다.
|
||||||
1. CNI 네트워크 플러그인을 구성한다.
|
1. CNI 네트워크 플러그인을 구성한다.
|
||||||
1. 선택된 네트워크 인터페이스 상에서 HNS 네트워크를 생성한다.
|
1. 선택된 네트워크 인터페이스 상에서 HNS 네트워크를 생성한다.
|
||||||
|
|
@ -328,7 +328,7 @@ kubectl get nodes
|
||||||
1. 등록된 모든 쿠버네티스 서비스(flanneld, kubelet, kube-proxy)를 해지한다.
|
1. 등록된 모든 쿠버네티스 서비스(flanneld, kubelet, kube-proxy)를 해지한다.
|
||||||
1. 쿠버네티스 바이너리(kube-proxy.exe, kubelet.exe, flanneld.exe, kubeadm.exe)를 모두 삭제한다.
|
1. 쿠버네티스 바이너리(kube-proxy.exe, kubelet.exe, flanneld.exe, kubeadm.exe)를 모두 삭제한다.
|
||||||
1. CNI 네트워크 플러그인 바이너리를 모두 삭제한다.
|
1. CNI 네트워크 플러그인 바이너리를 모두 삭제한다.
|
||||||
1. 쿠버네티스 클러스터에 접근하기 위한 [Kubeconfig 파일](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 삭제한다.
|
1. 쿠버네티스 클러스터에 접근하기 위한 [Kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 삭제한다.
|
||||||
|
|
||||||
|
|
||||||
### 퍼블릭 클라우드 제공자
|
### 퍼블릭 클라우드 제공자
|
||||||
|
|
|
||||||
|
|
@ -179,7 +179,7 @@ Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와
|
||||||
|
|
||||||
### 다른 언어
|
### 다른 언어
|
||||||
|
|
||||||
다른 언어에서 API를 접속하기 위한 [클라이언트 라이브러리들](/docs/reference/using-api/client-libraries/)도 존재한다.
|
다른 언어에서 API를 접속하기 위한 [클라이언트 라이브러리들](/ko/docs/reference/using-api/client-libraries/)도 존재한다.
|
||||||
이들이 어떻게 인증하는지는 다른 라이브러리들의 문서를 참조한다.
|
이들이 어떻게 인증하는지는 다른 라이브러리들의 문서를 참조한다.
|
||||||
|
|
||||||
## 파드에서 API 액세스
|
## 파드에서 API 액세스
|
||||||
|
|
|
||||||
|
|
@ -322,7 +322,7 @@ contexts:
|
||||||
```
|
```
|
||||||
|
|
||||||
kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
|
kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
|
||||||
[kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)를 참조한다.
|
[kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)를 참조한다.
|
||||||
|
|
||||||
## $HOME/.kube 디렉토리 탐색
|
## $HOME/.kube 디렉토리 탐색
|
||||||
|
|
||||||
|
|
@ -372,7 +372,7 @@ Windows PowerShell
|
||||||
|
|
||||||
{{% capture whatsnext %}}
|
{{% capture whatsnext %}}
|
||||||
|
|
||||||
* [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
* [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
|
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
|
||||||
|
|
@ -2,6 +2,7 @@
|
||||||
title: 포트 포워딩을 사용해서 클러스터 내 애플리케이션에 접근하기
|
title: 포트 포워딩을 사용해서 클러스터 내 애플리케이션에 접근하기
|
||||||
content_template: templates/task
|
content_template: templates/task
|
||||||
weight: 40
|
weight: 40
|
||||||
|
min-kubernetes-server-version: v1.10
|
||||||
---
|
---
|
||||||
|
|
||||||
{{% capture overview %}}
|
{{% capture overview %}}
|
||||||
|
|
@ -26,104 +27,156 @@ weight: 40
|
||||||
|
|
||||||
## Redis 디플로이먼트와 서비스 생성하기
|
## Redis 디플로이먼트와 서비스 생성하기
|
||||||
|
|
||||||
1. Redis 디플로이먼트를 생성한다.
|
1. Redis를 실행하기 위해 디플로이먼트를 생성한다.
|
||||||
|
|
||||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
|
```shell
|
||||||
|
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
|
||||||
|
```
|
||||||
|
|
||||||
성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다.
|
성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다.
|
||||||
|
|
||||||
deployment.apps/redis-master created
|
```
|
||||||
|
deployment.apps/redis-master created
|
||||||
|
```
|
||||||
|
|
||||||
파드 상태를 조회하여 파드가 준비되었는지 확인한다.
|
파드 상태를 조회하여 파드가 준비되었는지 확인한다.
|
||||||
|
|
||||||
kubectl get pods
|
```shell
|
||||||
|
kubectl get pods
|
||||||
|
```
|
||||||
|
|
||||||
출력은 파드가 생성되었다는 것을 보여준다.
|
출력은 파드가 생성되었다는 것을 보여준다.
|
||||||
|
|
||||||
NAME READY STATUS RESTARTS AGE
|
```
|
||||||
redis-master-765d459796-258hz 1/1 Running 0 50s
|
NAME READY STATUS RESTARTS AGE
|
||||||
|
redis-master-765d459796-258hz 1/1 Running 0 50s
|
||||||
|
```
|
||||||
|
|
||||||
디플로이먼트 상태를 조회한다.
|
디플로이먼트 상태를 조회한다.
|
||||||
|
|
||||||
kubectl get deployment
|
```shell
|
||||||
|
kubectl get deployment
|
||||||
|
```
|
||||||
|
|
||||||
출력은 디플로이먼트가 생성되었다는 것을 보여준다.
|
출력은 디플로이먼트가 생성되었다는 것을 보여준다.
|
||||||
|
|
||||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
```
|
||||||
redis-master 1/1 1 1 55s
|
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||||
|
redis-master 1/1 1 1 55s
|
||||||
|
```
|
||||||
|
|
||||||
아래의 명령어를 사용하여 레플리카셋 상태를 조회한다.
|
아래의 명령어를 사용하여 레플리카셋 상태를 조회한다.
|
||||||
|
|
||||||
kubectl get rs
|
```shell
|
||||||
|
kubectl get rs
|
||||||
|
```
|
||||||
|
|
||||||
출력은 레플리카셋이 생성되었다는 것을 보여준다.
|
출력은 레플리카셋이 생성되었다는 것을 보여준다.
|
||||||
|
|
||||||
NAME DESIRED CURRENT READY AGE
|
```
|
||||||
redis-master-765d459796 1 1 1 1m
|
NAME DESIRED CURRENT READY AGE
|
||||||
|
redis-master-765d459796 1 1 1 1m
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
2. Redis 서비스를 생성한다.
|
2. Redis를 네트워크에 노출시키기 위해 서비스를 생성한다.
|
||||||
|
|
||||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
|
```shell
|
||||||
|
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
|
||||||
|
```
|
||||||
|
|
||||||
성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다.
|
성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다.
|
||||||
|
|
||||||
service/redis-master created
|
```
|
||||||
|
service/redis-master created
|
||||||
|
```
|
||||||
|
|
||||||
서비스가 생성되었는지 확인한다.
|
서비스가 생성되었는지 확인한다.
|
||||||
|
|
||||||
kubectl get svc | grep redis
|
```shell
|
||||||
|
kubectl get svc | grep redis
|
||||||
|
```
|
||||||
|
|
||||||
출력은 서비스가 생성되었다는 것을 보여준다.
|
출력은 서비스가 생성되었다는 것을 보여준다.
|
||||||
|
|
||||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
```
|
||||||
redis-master ClusterIP 10.0.0.213 <none> 6379/TCP 27s
|
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||||
|
redis-master ClusterIP 10.0.0.213 <none> 6379/TCP 27s
|
||||||
|
```
|
||||||
|
|
||||||
3. Redis 서버가 파드 안에서 실행되고 있고, 6379번 포트에서 수신하고 있는지 확인한다.
|
3. Redis 서버가 파드 안에서 실행되고 있고, 6379번 포트에서 수신하고 있는지 확인한다.
|
||||||
|
|
||||||
kubectl get pods redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
|
```shell
|
||||||
|
# redis-master-765d459796-258hz 를 파드 이름으로 변경한다.
|
||||||
|
kubectl get pod redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
|
||||||
|
|
||||||
출력은 포트 번호를 보여준다.
|
```
|
||||||
|
|
||||||
6379
|
출력은 파드 내 Redis 포트 번호를 보여준다.
|
||||||
|
|
||||||
|
```
|
||||||
|
6379
|
||||||
|
```
|
||||||
|
|
||||||
|
(이 TCP 포트는 Redis가 인터넷에 할당된 것이다).
|
||||||
|
|
||||||
## 파드의 포트를 로컬 포트로 포워딩하기
|
## 파드의 포트를 로컬 포트로 포워딩하기
|
||||||
|
|
||||||
1. 쿠버네티스 1.10 버전부터, `kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다.
|
1. `kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다.
|
||||||
|
|
||||||
kubectl port-forward redis-master-765d459796-258hz 7000:6379
|
```shell
|
||||||
|
# redis-master-765d459796-258hz 를 파드 이름으로 변경한다.
|
||||||
|
kubectl port-forward redis-master-765d459796-258hz 7000:6379
|
||||||
|
```
|
||||||
|
|
||||||
이것은
|
이것은
|
||||||
|
|
||||||
kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379
|
```shell
|
||||||
|
kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379
|
||||||
|
```
|
||||||
|
|
||||||
또는
|
또는
|
||||||
|
|
||||||
kubectl port-forward deployment/redis-master 7000:6379
|
```shell
|
||||||
|
kubectl port-forward deployment/redis-master 7000:6379
|
||||||
|
```
|
||||||
|
|
||||||
또는
|
또는
|
||||||
|
|
||||||
kubectl port-forward rs/redis-master 7000:6379
|
```shell
|
||||||
|
kubectl port-forward rs/redis-master 7000:6379
|
||||||
|
```
|
||||||
|
|
||||||
또는 다음과 같다.
|
또는 다음과 같다.
|
||||||
|
|
||||||
kubectl port-forward svc/redis-master 7000:6379
|
```shell
|
||||||
|
kubectl port-forward svc/redis-master 7000:6379
|
||||||
|
```
|
||||||
|
|
||||||
위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다.
|
위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다.
|
||||||
|
|
||||||
I0710 14:43:38.274550 3655 portforward.go:225] Forwarding from 127.0.0.1:7000 -> 6379
|
```
|
||||||
I0710 14:43:38.274797 3655 portforward.go:225] Forwarding from [::1]:7000 -> 6379
|
I0710 14:43:38.274550 3655 portforward.go:225] Forwarding from 127.0.0.1:7000 -> 6379
|
||||||
|
I0710 14:43:38.274797 3655 portforward.go:225] Forwarding from [::1]:7000 -> 6379
|
||||||
|
```
|
||||||
|
|
||||||
2. Redis 커맨드라인 인터페이스를 실행한다.
|
2. Redis 커맨드라인 인터페이스를 실행한다.
|
||||||
|
|
||||||
redis-cli -p 7000
|
```shell
|
||||||
|
redis-cli -p 7000
|
||||||
|
```
|
||||||
|
|
||||||
3. Redis 커맨드라인 프롬프트에 `ping` 명령을 입력한다.
|
3. Redis 커맨드라인 프롬프트에 `ping` 명령을 입력한다.
|
||||||
|
|
||||||
127.0.0.1:7000>ping
|
```shell
|
||||||
|
ping
|
||||||
|
```
|
||||||
|
|
||||||
성공적인 핑 요청은 PONG을 반환한다.
|
성공적인 핑 요청을 반환한다.
|
||||||
|
|
||||||
|
```
|
||||||
|
PONG
|
||||||
|
```
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
@ -136,11 +189,12 @@ weight: 40
|
||||||
이 연결로 로컬 워크스테이션에서 파드 안에서 실행 중인 데이터베이스를 디버깅하는데
|
이 연결로 로컬 워크스테이션에서 파드 안에서 실행 중인 데이터베이스를 디버깅하는데
|
||||||
사용할 수 있다.
|
사용할 수 있다.
|
||||||
|
|
||||||
{{< warning >}}
|
{{< note >}}
|
||||||
알려진 제한사항으로 인해, 오늘날 포트 포워딩은 TCP 프로토콜에서만 작동한다. UDP 프로토콜에 대한 지원은
|
`kubectl port-forward` 는 TCP 포트에서만 구현된다.
|
||||||
|
UDP 프로토콜에 대한 지원은
|
||||||
[이슈 47862](https://github.com/kubernetes/kubernetes/issues/47862)
|
[이슈 47862](https://github.com/kubernetes/kubernetes/issues/47862)
|
||||||
에서 추적되고 있다.
|
에서 추적되고 있다.
|
||||||
{{< /warning >}}
|
{{< /note >}}
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -109,7 +109,7 @@ track=stable
|
||||||
|
|
||||||
- **이미지 풀(Pull) 시크릿**: 특정 도커 컨테이너 이미지가 프라이빗한 경우, [풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 증명을 요구한다.
|
- **이미지 풀(Pull) 시크릿**: 특정 도커 컨테이너 이미지가 프라이빗한 경우, [풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 증명을 요구한다.
|
||||||
|
|
||||||
대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성 할 수 있도록 한다. 시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다. 시크릿 내용은 base64 인코딩 방식이며, [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 파일로 정의된다. 시크릿 이름은 최대 253 문자를 포함할 수 있다.
|
대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성 할 수 있도록 한다. 시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다. 시크릿 내용은 base64 인코딩 방식이며, [`.dockercfg`](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시) 파일로 정의된다. 시크릿 이름은 최대 253 문자를 포함할 수 있다.
|
||||||
|
|
||||||
이미지 풀(Pull) 시크릿의 생성이 성공한 경우, 기본으로 선택된다. 만약 생성에 실패하면, 시크릿은 허용되지 않는다.
|
이미지 풀(Pull) 시크릿의 생성이 성공한 경우, 기본으로 선택된다. 만약 생성에 실패하면, 시크릿은 허용되지 않는다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -81,7 +81,7 @@ service/php-apache created
|
||||||
간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다.
|
간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다.
|
||||||
(kubectl run으로 각 파드는 200 밀리코어까지 요청할 수 있고,
|
(kubectl run으로 각 파드는 200 밀리코어까지 요청할 수 있고,
|
||||||
따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다).
|
따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다).
|
||||||
이에 대한 자세한 알고리즘은 [여기](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)를 참고하기 바란다.
|
이에 대한 자세한 알고리즘은 [여기](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#알고리즘-세부-정보)를 참고하기 바란다.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
|
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
|
||||||
|
|
@ -367,8 +367,8 @@ status:
|
||||||
type: Object
|
type: Object
|
||||||
object:
|
object:
|
||||||
metric:
|
metric:
|
||||||
name: `http_requests`
|
name: http_requests
|
||||||
selector: `verb=GET`
|
selector: {matchLabels: {verb: GET}}
|
||||||
```
|
```
|
||||||
|
|
||||||
이 셀렉터는 쿠버네티스의 레이블 셀렉터와 동일한 문법이다.
|
이 셀렉터는 쿠버네티스의 레이블 셀렉터와 동일한 문법이다.
|
||||||
|
|
|
||||||
|
|
@ -67,7 +67,7 @@ Horizontal Pod Autoscaler는 컨트롤러
|
||||||
HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
|
HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
|
||||||
`custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로
|
`custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로
|
||||||
시작해야 하는 메트릭-서버에 의해 제공된다. 가이드는
|
시작해야 하는 메트릭-서버에 의해 제공된다. 가이드는
|
||||||
[메트릭-서버](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)를
|
[메트릭-서버](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를
|
||||||
참조한다. HorizontalPodAutoscaler는 힙스터(Heapster)에서 직접 메트릭을 가져올 수도 있다.
|
참조한다. HorizontalPodAutoscaler는 힙스터(Heapster)에서 직접 메트릭을 가져올 수도 있다.
|
||||||
|
|
||||||
{{< note >}}
|
{{< note >}}
|
||||||
|
|
@ -178,6 +178,8 @@ CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은
|
||||||
`autoscaling/v2beta2`에서 확인할 수 있다. `autoscaling/v2beta2`에서 소개된
|
`autoscaling/v2beta2`에서 확인할 수 있다. `autoscaling/v2beta2`에서 소개된
|
||||||
새로운 필드는 `autoscaling/v1`로 작업할 때 어노테이션으로 보존된다.
|
새로운 필드는 `autoscaling/v1`로 작업할 때 어노테이션으로 보존된다.
|
||||||
|
|
||||||
|
HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한
|
||||||
|
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)인지 확인해야 한다.
|
||||||
API 오브젝트에 대한 자세한 내용은
|
API 오브젝트에 대한 자세한 내용은
|
||||||
[HorizontalPodAutoscaler 오브젝트](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)에서 찾을 수 있다.
|
[HorizontalPodAutoscaler 오브젝트](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)에서 찾을 수 있다.
|
||||||
|
|
||||||
|
|
@ -284,8 +286,8 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
|
||||||
[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md),
|
[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md),
|
||||||
[external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md)를 참조한다.
|
[external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md)를 참조한다.
|
||||||
|
|
||||||
어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)과
|
어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#다양한-메트릭-및-사용자-정의-메트릭을-기초로한-오토스케일링)과
|
||||||
[외부 메트릭스 사용하는 작업 과정](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)을 참조한다.
|
[외부 메트릭스 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#쿠버네티스-오브젝트와-관련이-없는-메트릭을-기초로한-오토스케일링)을 참조한다.
|
||||||
|
|
||||||
## 구성가능한 스케일링 동작 지원
|
## 구성가능한 스케일링 동작 지원
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -86,6 +86,12 @@ Minikube에서는 동작하지 않는 스냅 패키지 대신 도커용 `.deb`
|
||||||
`--vm-driver=none` 을 사용하기 전에 [이 문서](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)를 참조해서 더 자세한 내용을 본다.
|
`--vm-driver=none` 을 사용하기 전에 [이 문서](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)를 참조해서 더 자세한 내용을 본다.
|
||||||
{{< /caution >}}
|
{{< /caution >}}
|
||||||
|
|
||||||
|
Minikube는 도커 드라이브와 비슷한 `vm-driver=podman` 도 지원한다. 슈퍼사용자 권한(root 사용자)으로 실행되는 Podman은 컨테이너가 시스템에서 사용 가능한 모든 기능에 완전히 접근할 수 있는 가장 좋은 방법이다.
|
||||||
|
|
||||||
|
{{< caution >}}
|
||||||
|
일반 사용자 계정은 컨테이너를 실행하는 데 필요한 모든 운영 체제 기능에 완전히 접근할 수 없기에 `podman` 드라이버는 컨테이너를 root로 실행해야 한다.
|
||||||
|
{{< /caution >}}
|
||||||
|
|
||||||
### 패키지를 이용하여 Minikube 설치
|
### 패키지를 이용하여 Minikube 설치
|
||||||
|
|
||||||
Minikube를 위한 *실험적인* 패키지가 있다.
|
Minikube를 위한 *실험적인* 패키지가 있다.
|
||||||
|
|
|
||||||
|
|
@ -22,8 +22,6 @@ content_template: templates/concept
|
||||||
|
|
||||||
* [쿠버네티스 기초](/ko/docs/tutorials/kubernetes-basics/)는 쿠버네티스 시스템을 이해하는데 도움이 되고 기초적인 쿠버네티스 기능을 일부 사용해 볼 수 있는 심도있는 대화형 튜토리얼이다.
|
* [쿠버네티스 기초](/ko/docs/tutorials/kubernetes-basics/)는 쿠버네티스 시스템을 이해하는데 도움이 되고 기초적인 쿠버네티스 기능을 일부 사용해 볼 수 있는 심도있는 대화형 튜토리얼이다.
|
||||||
|
|
||||||
* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
|
|
||||||
|
|
||||||
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
|
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
|
||||||
|
|
||||||
* [Hello Minikube](/ko/docs/tutorials/hello-minikube/)
|
* [Hello Minikube](/ko/docs/tutorials/hello-minikube/)
|
||||||
|
|
|
||||||
|
|
@ -90,7 +90,7 @@ weight: 10
|
||||||
</div>
|
</div>
|
||||||
<div class="col-md-4">
|
<div class="col-md-4">
|
||||||
<div class="content__box content__box_fill">
|
<div class="content__box content__box_fill">
|
||||||
<p><i>마스터는 클러스터를 관리하고 노드는 구동되는 애플리케이션을 수용하는데 사용된다. </i></p>
|
<p><i>마스터는 실행 중인 애플리케이션을 호스팅하는 데 사용되는 클러스터와 노드를 관리한다. </i></p>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
|
|
|
||||||
|
|
@ -17,6 +17,14 @@ weight: 20
|
||||||
|
|
||||||
<main class="content katacoda-content">
|
<main class="content katacoda-content">
|
||||||
|
|
||||||
|
<div class="row">
|
||||||
|
<div class="col-md-12">
|
||||||
|
<p>
|
||||||
|
파드는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 각 파드는 클러스터에서 실행중인 워크로드의 일부를 나타낸다. <a href="/ko/docs/concepts/workloads/pods/pod-overview/#파드에-대해-이해하기">파드에 대해 더 자세히 알아본다</a>.
|
||||||
|
</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
<br>
|
<br>
|
||||||
<div class="katacoda">
|
<div class="katacoda">
|
||||||
<div class="katacoda__alert">
|
<div class="katacoda__alert">
|
||||||
|
|
|
||||||
|
|
@ -79,13 +79,8 @@ weight: 10
|
||||||
<li>임베디드된 버전 태그들</li>
|
<li>임베디드된 버전 태그들</li>
|
||||||
<li>태그들을 이용하는 객체들에 대한 분류</li>
|
<li>태그들을 이용하는 객체들에 대한 분류</li>
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
</div>
|
|
||||||
<div class="col-md-4">
|
|
||||||
<div class="content__box content__box_fill">
|
|
||||||
<p><i>여러분은 kubectl 명령에<br><code>--expose</code> 옵션을 사용함으로써 디플로이먼트 생성과 동일 시점에 서비스를 생성할 수 있다.</i></p>
|
|
||||||
</div>
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<br>
|
<br>
|
||||||
|
|
|
||||||
|
|
@ -1,5 +0,0 @@
|
||||||
---
|
|
||||||
title: "온라인 트레이닝 코스"
|
|
||||||
weight: 20
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
@ -1,71 +0,0 @@
|
||||||
---
|
|
||||||
title: 쿠버네티스 온라인 트레이닝 개요
|
|
||||||
content_template: templates/concept
|
|
||||||
---
|
|
||||||
|
|
||||||
{{% capture overview %}}
|
|
||||||
|
|
||||||
이 페이지에서는 쿠버네티스 온라인 트레이닝을 제공하는 사이트를 소개한다.
|
|
||||||
|
|
||||||
{{% /capture %}}
|
|
||||||
|
|
||||||
{{% capture body %}}
|
|
||||||
|
|
||||||
* [AIOps Essentials (Autoscaling Kubernetes with Prometheus Metrics) with Hands-On Labs (Linux Academy)](https://linuxacademy.com/devops/training/course/name/using-machine-learning-to-scale-kubernetes-clusters)
|
|
||||||
|
|
||||||
* [Amazon EKS Deep Dive with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/amazon-web-services/training/course/name/amazon-eks-deep-dive)
|
|
||||||
|
|
||||||
* [Cloud Native Certified Kubernetes Administrator (CKA) with Hands-On Labs & Practice Exams (Linux Academy)](https://linuxacademy.com/linux/training/course/name/cloud-native-certified-kubernetes-administrator-cka)
|
|
||||||
|
|
||||||
* [Certified Kubernetes Administrator (CKA) Preparation Course (CloudYuga)](https://cloudyuga.guru/courses/cka-online-self-paced)
|
|
||||||
|
|
||||||
* [Certified Kubernetes Administrator Preparation Course with Practice Tests (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests)
|
|
||||||
|
|
||||||
* [Certified Kubernetes Application Developer (CKAD) with Hands-On Labs & Practice Exams (Linux Academy)] (https://linuxacademy.com/containers/training/course/name/certified-kubernetes-application-developer-ckad/)
|
|
||||||
|
|
||||||
* [Certified Kubernetes Application Developer (CKAD) Preparation Course (CloudYuga)](https://cloudyuga.guru/courses/ckad-online-self-paced)
|
|
||||||
|
|
||||||
* [Certified Kubernetes Application Developer Preparation Course with Practice Tests (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course)
|
|
||||||
|
|
||||||
* [Getting Started with Google Kubernetes Engine (Coursera)](https://www.coursera.org/learn/google-kubernetes-engine)
|
|
||||||
|
|
||||||
* [Getting Started with Kubernetes (Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes)
|
|
||||||
|
|
||||||
* [Getting Started with Kubernetes Clusters on OCI Oracle Kubernetes Engine (OKE) (Learning Library)](https://apexapps.oracle.com/pls/apex/f?p=44785:50:0:::50:P50_EVENT_ID,P50_COURSE_ID:5935,256)
|
|
||||||
|
|
||||||
* [Google Kubernetes Engine Deep Dive (Linux Academy)] (https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive)
|
|
||||||
|
|
||||||
* [Helm Deep Dive with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/helm-deep-dive-part-1)
|
|
||||||
|
|
||||||
* [Hands-on Introduction to Kubernetes (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes)
|
|
||||||
|
|
||||||
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
|
|
||||||
|
|
||||||
* [Kubernetes Essentials with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)
|
|
||||||
|
|
||||||
* [Kubernetes for the Absolute Beginners with Hands-on Labs (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)
|
|
||||||
|
|
||||||
* [Kubernetes Fundamentals (LFS258) (The Linux Foundation)](https://training.linuxfoundation.org/training/kubernetes-fundamentals/)
|
|
||||||
|
|
||||||
* [Kubernetes Quick Start with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start)
|
|
||||||
|
|
||||||
* [Kubernetes the Hard Way with Hands-On Labs (Linux Academy)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way)
|
|
||||||
|
|
||||||
* [Kubernetes Security with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-security)
|
|
||||||
|
|
||||||
* [Launch Your First OpenShift Operator with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/containers/training/course/name/red-hat-open-shift)
|
|
||||||
|
|
||||||
* [Learn Kubernetes by Doing - 100% Hands-On Experience (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/learn-kubernetes-by-doing)
|
|
||||||
|
|
||||||
* [Learn Kubernetes using Interactive Hands-on Scenarios (Katacoda)](https://www.katacoda.com/courses/kubernetes/)
|
|
||||||
|
|
||||||
* [Microservice Applications in Kubernetes - 100% Hands-On Experience (Linux Academy)] (https://linuxacademy.com/devops/training/course/name/learn-microservices-by-doing)
|
|
||||||
|
|
||||||
* [Monitoring Kubernetes With Prometheus with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus)
|
|
||||||
|
|
||||||
* [Service Mesh with Istio with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/service-mesh-with-istio-part-1)
|
|
||||||
|
|
||||||
* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
|
|
||||||
|
|
||||||
* [Self-paced Kubernetes online course (Learnk8s Academy)](https://learnk8s.io/academy)
|
|
||||||
{{% /capture %}}
|
|
||||||
|
|
@ -1,6 +1,7 @@
|
||||||
---
|
---
|
||||||
title: 소스 IP 주소 이용하기
|
title: 소스 IP 주소 이용하기
|
||||||
content_template: templates/tutorial
|
content_template: templates/tutorial
|
||||||
|
min-kubernetes-server-version: v1.5
|
||||||
---
|
---
|
||||||
|
|
||||||
{{% capture overview %}}
|
{{% capture overview %}}
|
||||||
|
|
@ -14,26 +15,38 @@ content_template: templates/tutorial
|
||||||
|
|
||||||
{{% capture prerequisites %}}
|
{{% capture prerequisites %}}
|
||||||
|
|
||||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
### 용어
|
||||||
|
|
||||||
## 용어
|
|
||||||
|
|
||||||
이 문서는 다음 용어를 사용한다.
|
이 문서는 다음 용어를 사용한다.
|
||||||
|
|
||||||
* [NAT](https://en.wikipedia.org/wiki/Network_address_translation): 네트워크 주소 변환
|
{{< comment >}}
|
||||||
* [소스 NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT): 패킷 상의 소스 IP 주소를 변경함, 보통 노드의 IP 주소
|
이 섹션을 현지화하는 경우 대상 지역에 대한 위키피디아
|
||||||
* [대상 NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT): 패킷 상의 대상 IP 주소를 변경함, 보통 파드의 IP 주소
|
페이지로 연결한다.
|
||||||
* [VIP](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시): 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은
|
{{< /comment >}}
|
||||||
* [Kube-proxy](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시): 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다.
|
|
||||||
|
|
||||||
|
[NAT](https://en.wikipedia.org/wiki/Network_address_translation)
|
||||||
|
: 네트워크 주소 변환
|
||||||
|
|
||||||
## 전제 조건
|
[소스 NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT)
|
||||||
|
: 패킷 상의 소스 IP 주소를 변경함, 보통 노드의 IP 주소
|
||||||
|
|
||||||
|
[대상 NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT)
|
||||||
|
: 패킷 상의 대상 IP 주소를 변경함, 보통 파드의 IP 주소
|
||||||
|
|
||||||
|
[VIP](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)
|
||||||
|
: 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은
|
||||||
|
|
||||||
|
[Kube-proxy](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)
|
||||||
|
: 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다.
|
||||||
|
|
||||||
|
### 전제 조건
|
||||||
|
|
||||||
|
{{< include "task-tutorial-prereqs.md" >}}
|
||||||
|
|
||||||
이 문서의 예시를 실행하기 위해서 쿠버네티스 1.5 이상의 동작하는 클러스터가 필요하다.
|
|
||||||
이 예시는 HTTP 헤더로 수신한 요청의 소스 IP 주소를 회신하는
|
이 예시는 HTTP 헤더로 수신한 요청의 소스 IP 주소를 회신하는
|
||||||
작은 nginx 웹 서버를 이용한다. 다음과 같이 생성할 수 있다.
|
작은 nginx 웹 서버를 이용한다. 다음과 같이 생성할 수 있다.
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4
|
kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4
|
||||||
```
|
```
|
||||||
출력은 다음과 같다.
|
출력은 다음과 같다.
|
||||||
|
|
@ -54,12 +67,13 @@ deployment.apps/source-ip-app created
|
||||||
|
|
||||||
{{% capture lessoncontent %}}
|
{{% capture lessoncontent %}}
|
||||||
|
|
||||||
## Type=ClusterIP인 서비스에서 소스 IP
|
## `Type=ClusterIP` 인 서비스에서 소스 IP
|
||||||
|
|
||||||
쿠버네티스 1.2부터 기본으로 제공하는
|
[iptables 모드](/ko/docs/concepts/services-networking/service/#proxy-mode-iptables)
|
||||||
[iptables 모드](/ko/docs/concepts/services-networking/service/#proxy-mode-iptables)로 운영하는 경우
|
(기본값)에서 kube-proxy를 운영하는 경우 클러스터 내에서
|
||||||
클러스터 내에서 클러스터 IP로 패킷을 보내면 소스 NAT를 통과하지 않는다.
|
클러스터IP로 패킷을 보내면
|
||||||
Kube-proxy는 이 모드를 `proxyMode` 엔드포인트를 통해 노출한다.
|
소스 NAT를 통과하지 않는다. kube-proxy가 실행중인 노드에서
|
||||||
|
`http://localhost:10249/proxyMode` 를 입력해서 kube-proxy 모드를 조회할 수 있다.
|
||||||
|
|
||||||
```console
|
```console
|
||||||
kubectl get nodes
|
kubectl get nodes
|
||||||
|
|
@ -71,9 +85,11 @@ kubernetes-node-6jst Ready <none> 2h v1.13.0
|
||||||
kubernetes-node-cx31 Ready <none> 2h v1.13.0
|
kubernetes-node-cx31 Ready <none> 2h v1.13.0
|
||||||
kubernetes-node-jj1t Ready <none> 2h v1.13.0
|
kubernetes-node-jj1t Ready <none> 2h v1.13.0
|
||||||
```
|
```
|
||||||
한 노드의 프록시 모드를 확인한다.
|
|
||||||
```console
|
한 노드의 프록시 모드를 확인한다. (kube-proxy는 포트 10249에서 수신대기한다.)
|
||||||
kubernetes-node-6jst $ curl localhost:10249/proxyMode
|
```shell
|
||||||
|
# 질의 할 노드의 쉘에서 이것을 실행한다.
|
||||||
|
curl localhost:10249/proxyMode
|
||||||
```
|
```
|
||||||
출력은 다음과 같다.
|
출력은 다음과 같다.
|
||||||
```
|
```
|
||||||
|
|
@ -82,23 +98,40 @@ iptables
|
||||||
|
|
||||||
소스 IP 애플리케이션을 통해 서비스를 생성하여 소스 IP 주소 보존 여부를 테스트할 수 있다.
|
소스 IP 애플리케이션을 통해 서비스를 생성하여 소스 IP 주소 보존 여부를 테스트할 수 있다.
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
$ kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080
|
kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080
|
||||||
|
```
|
||||||
|
출력은 다음과 같다.
|
||||||
|
```
|
||||||
service/clusterip exposed
|
service/clusterip exposed
|
||||||
|
```
|
||||||
$ kubectl get svc clusterip
|
```shell
|
||||||
|
kubectl get svc clusterip
|
||||||
|
```
|
||||||
|
출력은 다음과 같다.
|
||||||
|
```
|
||||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||||
clusterip ClusterIP 10.0.170.92 <none> 80/TCP 51s
|
clusterip ClusterIP 10.0.170.92 <none> 80/TCP 51s
|
||||||
```
|
```
|
||||||
|
|
||||||
그리고 동일한 클러스터의 파드에서 `클러스터IP`를 치면:
|
그리고 동일한 클러스터의 파드에서 `클러스터IP`를 치면:
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
$ kubectl run busybox -it --image=busybox --restart=Never --rm
|
kubectl run busybox -it --image=busybox --restart=Never --rm
|
||||||
|
```
|
||||||
|
출력은 다음과 같다.
|
||||||
|
```
|
||||||
Waiting for pod default/busybox to be running, status is Pending, pod ready: false
|
Waiting for pod default/busybox to be running, status is Pending, pod ready: false
|
||||||
If you don't see a command prompt, try pressing enter.
|
If you don't see a command prompt, try pressing enter.
|
||||||
|
|
||||||
# ip addr
|
```
|
||||||
|
그런 다음 해당 파드 내에서 명령을 실행할 수 있다.
|
||||||
|
|
||||||
|
```shell
|
||||||
|
# "kubectl run" 으로 터미널 내에서 이것을 실행한다.
|
||||||
|
ip addr
|
||||||
|
```
|
||||||
|
```
|
||||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
|
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
|
||||||
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
||||||
inet 127.0.0.1/8 scope host lo
|
inet 127.0.0.1/8 scope host lo
|
||||||
|
|
@ -111,26 +144,38 @@ If you don't see a command prompt, try pressing enter.
|
||||||
valid_lft forever preferred_lft forever
|
valid_lft forever preferred_lft forever
|
||||||
inet6 fe80::188a:84ff:feb0:26a5/64 scope link
|
inet6 fe80::188a:84ff:feb0:26a5/64 scope link
|
||||||
valid_lft forever preferred_lft forever
|
valid_lft forever preferred_lft forever
|
||||||
|
```
|
||||||
|
|
||||||
# wget -qO - 10.0.170.92
|
그런 다음 `wget` 을 사용해서 로컬 웹 서버에 쿼리한다.
|
||||||
|
```shell
|
||||||
|
# 10.0.170.92를 파드의 IPv4 주소로 변경한다.
|
||||||
|
wget -qO - 10.0.170.92
|
||||||
|
```
|
||||||
|
```
|
||||||
CLIENT VALUES:
|
CLIENT VALUES:
|
||||||
client_address=10.244.3.8
|
client_address=10.244.3.8
|
||||||
command=GET
|
command=GET
|
||||||
...
|
...
|
||||||
```
|
```
|
||||||
client_address는 클라이언트 파드와 서버 파드가 같은 노드 또는 다른 노드에 있는지 여부에 관계없이 항상 클라이언트 파드의 IP 주소이다.
|
`client_address` 는 클라이언트 파드와 서버 파드가 같은 노드 또는 다른 노드에 있는지 여부에 관계없이 항상 클라이언트 파드의 IP 주소이다.
|
||||||
|
|
||||||
## Type=NodePort인 서비스에서 소스 IP
|
## `Type=NodePort` 인 서비스에서 소스 IP
|
||||||
|
|
||||||
쿠버네티스 1.5부터 [Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport)인 서비스로 보내진 패킷은
|
[`Type=NodePort`](/ko/docs/concepts/services-networking/service/#nodeport)인
|
||||||
|
서비스로 보내진 패킷은
|
||||||
소스 NAT가 기본으로 적용된다. `NodePort` 서비스를 생성하여 이것을 테스트할 수 있다.
|
소스 NAT가 기본으로 적용된다. `NodePort` 서비스를 생성하여 이것을 테스트할 수 있다.
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
$ kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
|
kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
|
||||||
|
```
|
||||||
|
출력은 다음과 같다.
|
||||||
|
```
|
||||||
service/nodeport exposed
|
service/nodeport exposed
|
||||||
|
```
|
||||||
|
|
||||||
$ NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
|
```shell
|
||||||
$ NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="IPAddress")].address }')
|
NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
|
||||||
|
NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="IPAddress")].address }')
|
||||||
```
|
```
|
||||||
|
|
||||||
클라우드 공급자 상에서 실행한다면,
|
클라우드 공급자 상에서 실행한다면,
|
||||||
|
|
@ -138,8 +183,11 @@ $ NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=
|
||||||
이제 위에 노드 포트로 할당받은 포트를 통해 클러스터 외부에서
|
이제 위에 노드 포트로 할당받은 포트를 통해 클러스터 외부에서
|
||||||
서비스에 도달할 수 있다.
|
서비스에 도달할 수 있다.
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
$ for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done
|
for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done
|
||||||
|
```
|
||||||
|
출력은 다음과 유사하다.
|
||||||
|
```
|
||||||
client_address=10.180.1.1
|
client_address=10.180.1.1
|
||||||
client_address=10.240.0.5
|
client_address=10.240.0.5
|
||||||
client_address=10.240.0.3
|
client_address=10.240.0.3
|
||||||
|
|
@ -169,26 +217,33 @@ client_address=10.240.0.3
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
이를 피하기 위해 쿠버네티스는 클라이언트 소스 IP 주소를 보존하는 기능이 있다.
|
이를 피하기 위해 쿠버네티스는
|
||||||
[(기능별 가용성은 여기에)](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip).
|
[클라이언트 소스 IP 주소를 보존](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)하는 기능이 있다.
|
||||||
`service.spec.externalTrafficPolicy`을 `Local`로 하면
|
`service.spec.externalTrafficPolicy` 의 값을 `Local` 로 하면
|
||||||
오직 로컬 엔드포인트로만 프록시 요청하고 다른 노드로 트래픽 전달하지 않으므로,
|
오직 로컬 엔드포인트로만 프록시 요청하고
|
||||||
원본 소스 IP 주소를 보존한다.
|
다른 노드로 트래픽 전달하지 않는다. 이 방법은 원본
|
||||||
만약 로컬 엔드 포인트가 없다면, 그 노드로 보내진 패킷은 버려지므로
|
소스 IP 주소를 보존한다. 만약 로컬 엔드 포인트가 없다면,
|
||||||
|
그 노드로 보내진 패킷은 버려지므로
|
||||||
패킷 처리 규칙에서 정확한 소스 IP 임을 신뢰할 수 있으므로,
|
패킷 처리 규칙에서 정확한 소스 IP 임을 신뢰할 수 있으므로,
|
||||||
패킷을 엔드포인트까지 전달할 수 있다.
|
패킷을 엔드포인트까지 전달할 수 있다.
|
||||||
|
|
||||||
다음과 같이 `service.spec.externalTrafficPolicy` 필드를 설정하자.
|
다음과 같이 `service.spec.externalTrafficPolicy` 필드를 설정하자.
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
$ kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||||||
|
```
|
||||||
|
출력은 다음과 같다.
|
||||||
|
```
|
||||||
service/nodeport patched
|
service/nodeport patched
|
||||||
```
|
```
|
||||||
|
|
||||||
이제 다시 테스트를 실행해보자.
|
이제 다시 테스트를 실행해보자.
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
$ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done
|
for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done
|
||||||
|
```
|
||||||
|
출력은 다음과 유사하다.
|
||||||
|
```
|
||||||
client_address=104.132.1.79
|
client_address=104.132.1.79
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
@ -202,7 +257,6 @@ client_address=104.132.1.79
|
||||||
* 클라이언트는 패킷을 엔드포인트를 가진 `node1:nodePort` 보낸다.
|
* 클라이언트는 패킷을 엔드포인트를 가진 `node1:nodePort` 보낸다.
|
||||||
* node1은 패킷을 올바른 소스 IP 주소로 엔드포인트로 라우팅 한다.
|
* node1은 패킷을 올바른 소스 IP 주소로 엔드포인트로 라우팅 한다.
|
||||||
|
|
||||||
|
|
||||||
시각적으로
|
시각적으로
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|
@ -219,10 +273,11 @@ client_address=104.132.1.79
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Type=LoadBalancer인 서비스에서 소스 IP
|
## `Type=LoadBalancer` 인 서비스에서 소스 IP
|
||||||
|
|
||||||
쿠버네티스 1.5 부터 [Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer)인 서비스로
|
[`Type=LoadBalancer`](/ko/docs/concepts/services-networking/service/#loadbalancer)인
|
||||||
보낸 패킷은 소스 NAT를 기본으로 하는데, `Ready` 상태로 모든 스케줄된 모든 쿠버네티스 노드는
|
서비스로 보낸 패킷은 소스 NAT를 기본으로 하는데, `Ready` 상태로
|
||||||
|
모든 스케줄된 모든 쿠버네티스 노드는
|
||||||
로드 밸런싱 트래픽에 적합하다. 따라서 엔드포인트가 없는 노드에
|
로드 밸런싱 트래픽에 적합하다. 따라서 엔드포인트가 없는 노드에
|
||||||
패킷이 도착하면 시스템은 엔드포인트를 *포함한* 노드에 프록시를
|
패킷이 도착하면 시스템은 엔드포인트를 *포함한* 노드에 프록시를
|
||||||
수행하고 패킷 상에서 노드의 IP 주소로 소스 IP 주소를 변경한다
|
수행하고 패킷 상에서 노드의 IP 주소로 소스 IP 주소를 변경한다
|
||||||
|
|
@ -230,15 +285,31 @@ client_address=104.132.1.79
|
||||||
|
|
||||||
로드밸런서를 통해 source-ip-app을 노출하여 테스트할 수 있다.
|
로드밸런서를 통해 source-ip-app을 노출하여 테스트할 수 있다.
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
$ kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer
|
kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer
|
||||||
|
```
|
||||||
|
출력은 다음과 같다.
|
||||||
|
```
|
||||||
service/loadbalancer exposed
|
service/loadbalancer exposed
|
||||||
|
```
|
||||||
|
|
||||||
$ kubectl get svc loadbalancer
|
서비스의 IP 주소를 출력한다.
|
||||||
|
```console
|
||||||
|
kubectl get svc loadbalancer
|
||||||
|
```
|
||||||
|
다음과 유사하게 출력된다.
|
||||||
|
```
|
||||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||||
loadbalancer LoadBalancer 10.0.65.118 104.198.149.140 80/TCP 5m
|
loadbalancer LoadBalancer 10.0.65.118 203.0.113.140 80/TCP 5m
|
||||||
|
```
|
||||||
|
|
||||||
$ curl 104.198.149.140
|
다음으로 이 서비스의 외부 IP에 요청을 전송한다.
|
||||||
|
|
||||||
|
```shell
|
||||||
|
curl 203.0.113.140
|
||||||
|
```
|
||||||
|
다음과 유사하게 출력된다.
|
||||||
|
```
|
||||||
CLIENT VALUES:
|
CLIENT VALUES:
|
||||||
client_address=10.240.0.5
|
client_address=10.240.0.5
|
||||||
...
|
...
|
||||||
|
|
@ -265,51 +336,74 @@ health check ---> node 1 node 2 <--- health check
|
||||||
|
|
||||||
이것은 어노테이션을 설정하여 테스트할 수 있다.
|
이것은 어노테이션을 설정하여 테스트할 수 있다.
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
$ kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||||||
```
|
```
|
||||||
|
|
||||||
쿠버네티스에 의해 `service.spec.healthCheckNodePort` 필드가
|
쿠버네티스에 의해 `service.spec.healthCheckNodePort` 필드가
|
||||||
즉각적으로 할당되는 것을 봐야 한다.
|
즉각적으로 할당되는 것을 봐야 한다.
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
$ kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
|
kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
|
||||||
|
```
|
||||||
|
출력은 다음과 유사하다.
|
||||||
|
```yaml
|
||||||
healthCheckNodePort: 32122
|
healthCheckNodePort: 32122
|
||||||
```
|
```
|
||||||
|
|
||||||
`service.spec.healthCheckNodePort` 필드는 `/healthz`에서 헬스 체크를 제공하는
|
`service.spec.healthCheckNodePort` 필드는 `/healthz`에서 헬스 체크를 제공하는
|
||||||
모든 노드의 포트를 가르킨다. 이것을 테스트할 수 있다.
|
모든 노드의 포트를 가르킨다. 이것을 테스트할 수 있다.
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl get pod -o wide -l run=source-ip-app
|
||||||
|
```
|
||||||
|
출력은 다음과 유사하다.
|
||||||
```
|
```
|
||||||
$ kubectl get pod -o wide -l run=source-ip-app
|
|
||||||
NAME READY STATUS RESTARTS AGE IP NODE
|
NAME READY STATUS RESTARTS AGE IP NODE
|
||||||
source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-node-6jst
|
source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-node-6jst
|
||||||
|
```
|
||||||
|
|
||||||
kubernetes-node-6jst $ curl localhost:32122/healthz
|
다양한 노드에서 `/healthz` 엔드포인트를 가져오려면 `curl` 을 사용한다.
|
||||||
|
```shell
|
||||||
|
# 선택한 노드에서 로컬로 이것을 실행한다.
|
||||||
|
curl localhost:32122/healthz
|
||||||
|
```
|
||||||
|
```
|
||||||
1 Service Endpoints found
|
1 Service Endpoints found
|
||||||
|
```
|
||||||
|
|
||||||
kubernetes-node-jj1t $ curl localhost:32122/healthz
|
다른 노드에서는 다른 결과를 얻을 수 있다.
|
||||||
|
```shell
|
||||||
|
# 선택한 노드에서 로컬로 이것을 실행한다.
|
||||||
|
curl localhost:32122/healthz
|
||||||
|
```
|
||||||
|
```
|
||||||
No Service Endpoints Found
|
No Service Endpoints Found
|
||||||
```
|
```
|
||||||
|
|
||||||
마스터에서 실행 중인 서비스 컨트롤러는 필요시에 클라우드 로드밸런서를 할당할 책임이 있다.
|
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에서
|
||||||
또한, 각 노드에 HTTP 헬스 체크를 이 포트와 경로로 할당한다.
|
실행중인 컨트롤러는 클라우드 로드 밸런서를 할당한다. 또한 같은 컨트롤러는
|
||||||
헬스체크가 실패한 엔드포인트를 포함하지 않은 2개 노드에서 10초를 기다리고
|
각 노드에서 포트/경로(port/path)를 가르키는 HTTP 상태 확인도 할당한다.
|
||||||
로드밸런서 IP 주소로 curl 하자.
|
엔드포인트가 없는 2개의 노드가 상태 확인에 실패할
|
||||||
|
때까지 약 10초간 대기한 다음,
|
||||||
|
`curl` 을 사용해서 로드밸런서의 IPv4 주소를 쿼리한다.
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
$ curl 104.198.149.140
|
curl 203.0.113.140
|
||||||
|
```
|
||||||
|
출력은 다음과 유사하다.
|
||||||
|
```
|
||||||
CLIENT VALUES:
|
CLIENT VALUES:
|
||||||
client_address=104.132.1.79
|
client_address=198.51.100.79
|
||||||
...
|
...
|
||||||
```
|
```
|
||||||
|
|
||||||
__크로스 플랫폼 지원__
|
## 크로스-플랫폼 지원
|
||||||
|
|
||||||
쿠버네티스 1.5부터 Type=LoadBalancer 서비스를 통한
|
일부 클라우드 공급자만 `Type=LoadBalancer` 를 사용하는
|
||||||
소스 IP 주소 보존을 지원하지만,
|
서비스를 통해 소스 IP 보존을 지원한다.
|
||||||
이는 클라우드 공급자(GCE, Azure)의 하위 집합으로 구현되어 있다. 실행 중인 클라우드 공급자에서
|
실행 중인 클라우드 공급자에서 몇 가지 다른 방법으로
|
||||||
몇 가지 다른 방법으로 로드밸런서를 요청하자.
|
로드밸런서를 요청한다.
|
||||||
|
|
||||||
1. 클라이언트 연결을 종료하고 새 연결을 여는 프록시를 이용한다.
|
1. 클라이언트 연결을 종료하고 새 연결을 여는 프록시를 이용한다.
|
||||||
이 경우 소스 IP 주소는 클라이언트 IP 주소가 아니고
|
이 경우 소스 IP 주소는 클라이언트 IP 주소가 아니고
|
||||||
|
|
@ -320,34 +414,35 @@ __크로스 플랫폼 지원__
|
||||||
끝나는 패킷 전달자를 이용한다.
|
끝나는 패킷 전달자를 이용한다.
|
||||||
|
|
||||||
첫 번째 범주의 로드밸런서는 진짜 클라이언트 IP를 통신하기 위해
|
첫 번째 범주의 로드밸런서는 진짜 클라이언트 IP를 통신하기 위해
|
||||||
HTTP [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) 헤더나
|
HTTP [Forwarded]](https://tools.ietf.org/html/rfc7239#section-5.2)
|
||||||
[프록시 프로토콜](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)같이 로드밸런서와
|
또는 [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For)
|
||||||
백엔드 간에 합의된 프로토콜을 사용해야 한다.
|
헤더 또는
|
||||||
|
[proxy protocol](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)과
|
||||||
|
같은 로드밸런서와 백엔드 간에 합의된 프로토콜을 사용해야 한다.
|
||||||
두 번째 범주의 로드밸런서는 서비스의 `service.spec.healthCheckNodePort` 필드의 저장된 포트를 가르키는
|
두 번째 범주의 로드밸런서는 서비스의 `service.spec.healthCheckNodePort` 필드의 저장된 포트를 가르키는
|
||||||
간단한 HTTP 헬스 체크를 생성하여
|
HTTP 헬스 체크를 생성하여
|
||||||
위에서 설명한 기능을 활용할 수 있다.
|
위에서 설명한 기능을 활용할 수 있다.
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
{{% capture cleanup %}}
|
{{% capture cleanup %}}
|
||||||
|
|
||||||
서비스를 삭제하자.
|
서비스를 삭제한다.
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
$ kubectl delete svc -l run=source-ip-app
|
kubectl delete svc -l run=source-ip-app
|
||||||
```
|
```
|
||||||
|
|
||||||
디플로이먼트와 리플리카 셋과 파드를 삭제하자.
|
디플로이먼트, 레플리카셋 그리고 파드를 삭제한다.
|
||||||
|
|
||||||
```console
|
```shell
|
||||||
$ kubectl delete deployment source-ip-app
|
kubectl delete deployment source-ip-app
|
||||||
```
|
```
|
||||||
|
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
{{% capture whatsnext %}}
|
{{% capture whatsnext %}}
|
||||||
* [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 공부하기
|
* [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 더 자세히 본다.
|
||||||
* [부하분산](/docs/user-guide/load-balancer)에 대해 더 공부하기
|
* 어떻게 [외부 로드밸런서 생성](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)하는지 본다.
|
||||||
{{% /capture %}}
|
{{% /capture %}}
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -232,7 +232,7 @@ kubectl apply -k ./
|
||||||
{{% capture whatsnext %}}
|
{{% capture whatsnext %}}
|
||||||
|
|
||||||
* [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자.
|
* [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자.
|
||||||
* [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)를 알아보자.
|
* [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)를 알아보자.
|
||||||
* [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자.
|
* [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자.
|
||||||
* 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자.
|
* 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -110,7 +110,7 @@ Elastic Cloud의 Elasticsearch 서비스로 연결한다면 **관리 서비스**
|
||||||
1. ELASTICSEARCH_USERNAME
|
1. ELASTICSEARCH_USERNAME
|
||||||
1. KIBANA_HOST
|
1. KIBANA_HOST
|
||||||
|
|
||||||
이 정보를 Elasticsearch 클러스터와 Kibana 호스트에 지정한다. 여기 예시가 있다.
|
이 정보를 Elasticsearch 클러스터와 Kibana 호스트에 지정한다. 여기 예시(또는 [*이 구성*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897)을 본다)가 있다.
|
||||||
|
|
||||||
#### `ELASTICSEARCH_HOSTS`
|
#### `ELASTICSEARCH_HOSTS`
|
||||||
1. Elastic의 Elasticsearch Helm 차트에서 노드 그룹(nodeGroup).
|
1. Elastic의 Elasticsearch Helm 차트에서 노드 그룹(nodeGroup).
|
||||||
|
|
|
||||||
|
|
@ -1,5 +0,0 @@
|
||||||
This guide assumes that you have a running Kubernetes Cluster Federation installation.
|
|
||||||
If not, then head over to the [federation admin guide](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) to learn how to
|
|
||||||
bring up a cluster federation (or have your cluster administrator do this for you).
|
|
||||||
Other tutorials, such as Kelsey Hightower's [Federated Kubernetes Tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation),
|
|
||||||
might also help you create a Federated Kubernetes cluster.
|
|
||||||
|
|
@ -0,0 +1,108 @@
|
||||||
|
---
|
||||||
|
title: 교육
|
||||||
|
bigheader: 쿠버네티스 교육과 인증
|
||||||
|
abstract: 교육 프로그램, 인증 그리고 파트너
|
||||||
|
layout: basic
|
||||||
|
cid: training
|
||||||
|
class: training
|
||||||
|
---
|
||||||
|
|
||||||
|
<div class="padded blue-bg">
|
||||||
|
<div class="main-section two-thirds-centered white-text">
|
||||||
|
<center>
|
||||||
|
<h2>클라우드 네이티브 커리어를 구축하세요</h2>
|
||||||
|
<p>쿠버네티스는 클라우드 네이티브 무브먼트의 핵심입니다. 리눅스 재단이 제공하는 교육과 인증 프로그램을 통해 커리어에 투자하고, 쿠버네티스를 배우며, 클라우드 네이티브 프로젝트를 성공적으로 수행하세요.</p>
|
||||||
|
</center>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<div class="main-section padded">
|
||||||
|
<center>
|
||||||
|
<h2>edX에서 무료 강좌 수강하기</h2>
|
||||||
|
</center>
|
||||||
|
<div class="col-container">
|
||||||
|
<div class="col-nav">
|
||||||
|
<center>
|
||||||
|
<h5>
|
||||||
|
<b>쿠버네티스 소개 <br> </b>
|
||||||
|
</h5>
|
||||||
|
<p>쿠버네티스를 배우고 싶습니까? 컨테이너화된 애플리케이션의 관리를 위한 이 강력한 시스템에 대해 심도있는 입문 교육을 받으세요.</p>
|
||||||
|
<br>
|
||||||
|
<a href="https://www.edx.org/course/introduction-to-kubernetes" target="_blank" class="button">강좌로 이동하기</a>
|
||||||
|
</center>
|
||||||
|
</div>
|
||||||
|
<div class="col-nav">
|
||||||
|
<center>
|
||||||
|
<h5>
|
||||||
|
<b>클라우드 인프라 기술 소개</b>
|
||||||
|
</h5>
|
||||||
|
<p>오픈 소스의 리더인 리눅스 재단으로부터 직접 클라우드를 구축하고 관리하는 기술의 기초를 배우세요.</p>
|
||||||
|
<br>
|
||||||
|
<a href="https://www.edx.org/course/introduction-to-cloud-infrastructure-technologies" target="_blank" class="button">강좌로 이동하기</a>
|
||||||
|
</center>
|
||||||
|
</div>
|
||||||
|
<div class="col-nav">
|
||||||
|
<center>
|
||||||
|
<h5>
|
||||||
|
<b>리눅스 소개</b>
|
||||||
|
</h5>
|
||||||
|
<p>리눅스를 배운 적이 없습니까? 새로 다시 배우기를 원하시나요? 주요 리눅스 배포판에 걸쳐서 그래픽 인터페이스와 커멘드 라인을 모두 사용할 수 있는 유용한 실무 지식을 개발하세요.</p>
|
||||||
|
<br>
|
||||||
|
<a href="https://www.edx.org/course/introduction-to-linux" target="_blank" class="button">강좌로 이동하기</a>
|
||||||
|
</center>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<div class="padded lighter-gray-bg">
|
||||||
|
<div class="main-section two-thirds-centered">
|
||||||
|
<center>
|
||||||
|
<h2>리눅스 재단과 함께 배우기</h2>
|
||||||
|
<p>리눅스 재단은 쿠버네티스 애플리케이션 개발과 운영 라이프사이클의 모든 측면에 대해 강사 주도와 자기 주도 학습 과정을 제공합니다.</p>
|
||||||
|
<br><br>
|
||||||
|
<a href="https://training.linuxfoundation.org/training/course-catalog/?_sft_technology=kubernetes" target="_blank" class="button">강좌 보기</a>
|
||||||
|
</center>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<div class="main-section padded">
|
||||||
|
<center>
|
||||||
|
<h2>쿠버네티스 공인 자격 획득하기</h2>
|
||||||
|
</center>
|
||||||
|
<div class="col-nav">
|
||||||
|
<center>
|
||||||
|
<h5>
|
||||||
|
<b>공인 쿠버네티스 애플리케이션 개발자(Certified Kubernetes Application Developer, CKAD)</b>
|
||||||
|
</h5>
|
||||||
|
<p>공인 쿠버네티스 애플리케이션 개발자 시험은 사용자가 쿠버네티스의 클라우드 네이티브 애플리케이션을 디자인, 구축, 구성과 노출을 할 수 있음을 인증합니다.</p>
|
||||||
|
<br>
|
||||||
|
<a href="https://training.linuxfoundation.org/certification/certified-kubernetes-application-developer-ckad/" target="_blank" class="button">인증으로 이동하기</a>
|
||||||
|
</center>
|
||||||
|
</div>
|
||||||
|
<div class="col-nav">
|
||||||
|
<center>
|
||||||
|
<h5>
|
||||||
|
<b>공인 쿠버네티스 관리자(Certified Kubernetes Administrator, CKA)</b>
|
||||||
|
</h5>
|
||||||
|
<p>공인 쿠버네티스 관리자 프로그램은 CKA가 쿠버네티스 관리자 직무을 수행할 수 있는 기술, 지식과 역량을 갖추고 있음을 보장합니다.</p>
|
||||||
|
<br>
|
||||||
|
<a href=https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">인증으로 이동하기</a>
|
||||||
|
</center>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<div class="padded lighter-gray-bg">
|
||||||
|
<div class="main-section two-thirds-centered">
|
||||||
|
<center>
|
||||||
|
<h2>쿠버네티스 교육 파트너</h2>
|
||||||
|
<p>쿠버네티스 교육 파트너 네트워크는 쿠버네티스 및 클라우드 네이티브 프로젝트를 위한 교육 서비스를 제공합니다.</p>
|
||||||
|
</center>
|
||||||
|
</div>
|
||||||
|
<div class="main-section landscape-section">
|
||||||
|
<iframe src="https://landscape.cncf.io/category=kubernetes-training-partner&format=logo-mode&grouping=category&embed=yes" frameborder="0" id="landscape" scrolling="no"></iframe>
|
||||||
|
<script src="https://landscape.cncf.io/iframeResizer.js"></script>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
Loading…
Reference in New Issue