쿠버네티스 기초 학습

개념

Kubernetes v1.13 문서는 더 이상 적극적으로 관리되지 않음. 현재 보고있는 문서는 정적 스냅샷임. 최신 문서를 위해서는, 다음을 참고. 최신 버전.

Edit This Page

페더레이션

Deprecated

쿠버네티스 API 리소스를 ‘있는 그대로’ 재사용하는 현재의 쿠버네티스 페더레이션 API Federation V1는 많은 특징에 의해서 알파 상태로 여겨지고 있다. 페더레이션 API를 GA 단계로 진화시키는데 명확한 길은 없지만, 쿠버네티스 API와 별도로 페더레이션 전용 API를 구현하기 위한 Federation V2에 대한 노력이 진행 중이다. 자세한 사항은 sig-multicluster 커뮤니티 페이지에서 확인할 수 있다.

이 페이지는 여러 쿠버네티스 클러스터를 페더레이션을 통해서 관리해야 하는 이유와 방법을 설명한다.

페더레이션 이유

페더레이션을 사용하면 여러 클러스터를 쉽게 관리할 수 있다. 이는 2가지 주요 빌딩 블록을 제공함으로써 이루어진다.

페더레이션이 가능하게 하는 다른 사례는 다음과 같다.

여러 클러스터를 운영하는 경우가 아니면 페더레이션은 필요 없다. 여러 클러스터가 필요한 이유의 일부는 다음과 같다.

주의 사항

페더레이션에는 매력적인 사례가 많지만, 다소 주의 해야 할 사항도 있다.

하이브리드 클라우드 역량

쿠버네티스 클러스터의 페더레이션은 다른 클라우드 제공자(예를 들어, Google 클라우드, AWS), 그리고 온-프레미스(예를 들어, OpenStack)에서 동작 중인 클러스터를 포함할 수 있다. Kubefed는 연합된 클러스터 배치에 권장되는 방법이다. 그 후에, API 리소스는 서로 다른 클러스터와 클라우드 제공자에 걸쳐 확장될 수 있다.

페더레이션 설치

여러 클러스터의 페더레이션 구성을 위해서는, 페더레이션 컨트롤 플레인을 우선적으로 설치해야 한다. 페더레이션 컨트롤 플레인의 설치를 위해서는 설치 가이드 를 따른다.

API 리소스

컨트롤 플레인이 설치되고 나면, 페더레이션 API 리소스 생성을 시작할 수 있다. 다음의 가이드는 일부 리소스에 대해서 자세히 설명한다.

API 참조 문서는 페더레이션 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) 또는 가용 영역(availability zone)에 존재한다. 다음과 같은 이유로, 쿠버네티스 클러스터의 모든 VM을 동일한 가용 영역에 두는 것을 추천한다.

가용 영역당 더 많은 VM이 포함되는 적은 수의 클러스터 실행을 추천한다. 다만, 여러 가용 영역 마다 여러 클러스터의 실행도 가능하다.

가용 영역당 더 적은 수의 클러스터가 선호되는 이유는 다음과 같다.

여러 클러스터가 필요한 이유는 다음을 포함한다.

적절한 클러스터 수 선택하기

쿠버네티스 클러스터의 수를 선택하는 것은 상대적으로 고정적인 선택이며, 가끔식만 재고된다. 대조적으로, 클러스터의 노드 수와 서비스 내의 파드 수는 부하와 규모 증가에 따라 빈번하게 변경될 수 있다.

클러스터의 수를 선택하기 위해서, 첫 번째로, 쿠버네티스에서 동작할 서비스의 모든 최종 사용자에게 적절한 지연 시간을 제공할 수 있는 지역들을 선택할 필요가 있다(만약 콘텐츠 전송 네트워크를 사용한다면, CDN-호스트된 콘텐츠의 지연 시간 요구사항 고려할 필요가 없음). 법적인 이슈 또한 이것에 영향을 줄 수 있다. 예를 들면, 어떤 글로벌 고객 기반의 회사는 US, AP, SA 지역 등 특정 지역에서 클러스터를 운영하도록 결정할 수도 있다. 지역의 수를 R이라 부르자.

두 번째로, 여전히 사용 가능한 상태에서, 얼마나 많은 클러스터가 동시에 사용할 수 없는 상태가 될 수 있는지 결정한다. 사용하지 않는 상태가 될 수 있는 수를 U라고 하자. 만약이 값에 확신이 없다면, 1이 괜찮은 선택이다.

클러스터 장애 상황에서 어느 지역으로든지 직접적인 트래픽에 대한 로드밸런싱이 허용된다면, R 또는 적어도 U + 1 이상의 클러스터가 있으면 된다. 만약 그렇지 않다면(예를 들어, 클러스터 장애 상황에서 모든 사용자에 대한 낮은 지연 시간을 유지하고 싶다면), R * (U + 1)(각 R 지역 내에 U + 1) 클러스터가 필요하다. 어느 경우든지, 각 클러스터는 다른 영역에 배치하도록 노력하는 것이 좋다.

마지막으로, 클러스터 중 어느 클러스터라도 쿠버네티스 클러스터에서 추천되는 최대 노드 수 보다 더 많은 노드가 필요하다면, 더 많은 클러스터가 필요할 것이다. 쿠버네티스 v1.3은 클러스터를 최대 1000노드까지 지원한다. 쿠버네티스 v1.8은 클러스터를 최대 5000 노드까지 지원한다. 더 자세한 가이드는 대규모 클러스터 구축하기에서 확인 가능하다.

다음 내용

피드백