쿠버네티스 구조 심층탐구
분산시스템 디자인 패턴
1) 사이드가 패턴
사이트가 패턴은 포드에 있는 다른 컨테이너를 메인 애플리케이션 컨테이너에 함께 배치하는것이다. 애플리케이션 컨테이너는 사이드카 컨테이너가 추가된것을 인지하지 못한채 자신의 역할을 수행한다. 중앙집중식 로깅 에이전트가 좋은 예다. 메인 컨테이너는 표준 출력 로그를 기록한다. 하지만 사이드카 컨테이너는 모든 로그를 중앙집중식 로깅 서비스로 전송하고 전체로 시스템과의 로그를 집계한다. 메인 애플리ㅔ이션에 중앙집중식 로그의 기록으 ㄹ위해 사이트카 컨테이너를 사용하면 큰 장점이 있다. 대표적인 장점은 중앙집중식 로깅정책을 갱신하거나 와전히 새로운 공급자로 전환할 경우 사이드카 컨테이너만 업데이트 하고 배포하면 된다.
2) 엠버서더 패턴
엠버서더 패턴은 우너격 서비스가 마치 로컬인 것처럼 운영되도록 일부 정책을 시행하는 것이다. 쓰기 작업용 마스터 하나와 읽기 작업용 복제본 다수로 구성된 레디스 클러스터가 엠버서더 패턴의 좋은 예다. 로컬 엠버서더 컨테이너는 프록시 역할을 하며 로컬호스트의 메인 애플리케이션 컨테이너에 레디스를 노출할 수 있다. 메인 애플리케이션 컨테이너는 localhost:6379(Redis 기본 포트)에 있는 레디스에 간단히 연결되지만 실제로 동일한 포드에서 동작중인 엠버서더에 연결된다. 엠버서더는 요청을 필터링 하고, 실제 레디스 마스터에게 쓰기요청을 보내고, 읽기 복제본 중 하나로 읽기 요청을 전송한다. 사이드카 패턴과 같이 메인 애플리케이션은 어떤 일이 일어나고 있는지 알지 못한다. 이것은 실제 로컬 레디스 환경에서 테스트할 경우 많은 도움이 된다. 또한 레디스 클러스터 구성의 변경이 잇는 경ㅇ우 엠버서더만 수정하면 되며 메인 애플리케이션은 아무런 영향을 받지 않는다.
3) 어댑터 패턴
어댑터 패턴은 메인 애플리케이션 컨테이너의 출력을 표준화 한는 것이다. 점진적으로 배포되는 서비스를 가정해보자. 이전 버전과 일치하지 않는 형식의 출력이 발생하고 그 출력을 사용하는 다른 서비스나 애플리케이션은 아직 업그레이드되지 않은 경우를 가정하자 이경우 어댑터 컨테이너는 새로운 애플리케이션 컨테이너와 함께 동일한 포드에 배포될 수 있으며 해당 출력을 사용하는 다른 서비스나 애플리케이션이 업그레이드 될때까지 이전 버전에 맞게 출력을 변경할 수 있다. 어댑터 컨테이너는 메인 애플리케이션 컨테이너와 파일 시스템을 공유하기 때문에 로컬 파일 시스템의 감시가 가능하며 새로운 애플리케이션이 무언가 쓰기 작업을 할 때마다 이를 즉시 변경한다.
4) 다중 노드 패턴
모든 단일 노드 패턴은 포드를 통해 쿠버네티스가 직접 지원한다. 반면 리더선출, 작업 큐, 분산수집 같은 다중노드패턴은 쿠버네티스의 직접적인 지원 없이 표준 인터페이스를 사용해 포드를 구성한 쿠버네티스에서 실행 가능한 접근 방식이다.
쿠버네티스 API
시스템과 시스템 기능이 제공하는 것을 이해하려면 시스템의 API에 많은 관심을 가져야 한다. 사용자는 API를 통해 시스템이 제공하는 기능을 포괄적으로 이해할 수 있다. 쿠버네티스는 다양한 목적과 대상을 위해 몇가지 REST API 집합을 공개한다. 일부 API는 주로 도구로 사용되며 일부 API는 개발자가 직접 사용할 수 있다. API가 지속적으로 개발되고 있다는 것은 매우 중요한 포인트다. 쿠버네티스 개발자는 기존 객체에 새로운 객체와 빌드를 추가해 API를 확장하고, 기존 객체와 필드의 이름바꾸기나 삭제를 피함으로써 API관리가 가능하도록 유지한다. 또한 모든 API 엔드포인트의 버전은 관리되며 알파나 베타 표기법을 사용해 관리하는 경우가 많다. 다음은 그 예다.
/api/vi1
/api/v2alpha1
개발자는 kubectl cli 또는 클라이언트의 라이브러리를 사용하거나 직접 REST API호출을 통해 API에 접근할 수 있다. API사용에는 정교한 인증과 권한 부여 메커니즘이있으며, 이것은 이후 장에서 설펴본다. 올바른 사용 권한이 있으면 다양한 쿠버네티스 객체를 나열하고, 보고, 생성하고, 업데이트, 삭제할 수 있다. 이 시점에서 API를 살짝 엿보자. API를 탐색하는 가장 좋은 방법은 API그룹을 이용하는 것이다. 일부 API그룹은 기본적으로 활성화되어 있다. 일부 그룹은 플래그를 이용해 활성화 또는 비활성화할 수 있다. 예를 들어 배치 V1 그룹을 비활성화 하고 배치 V2 알파 카룹을 활성화 하려면 다음과 같이 API서버를 실행할때 --runtime-config 플래그를 설정할 수 있다.
--runtime-config=batch/v1=false,batch/v2alpha=true
'PaaS > Kubernetes' 카테고리의 다른 글
| (Kubernetes) Platform9의 PMK 란? (0) | 2021.12.18 |
|---|---|
| (개념) Ingress Controller 선택방법 Part1, 너의 요구사항을 인식해라 (0) | 2021.10.22 |
| (Notice) Kubernetes Cluster API 프로젝트 진척상황 (0) | 2021.10.09 |
| (Kubernetes) 외부에서 Kubernetes 리소스 접근을 위한 SA Token 생성 (0) | 2021.10.08 |
| (세미나) 2021 Kubernetes Community 발표회 정리 (0) | 2021.09.09 |