쿠버네티스 아키텍처란? 중요성 + 모범 사례

Kubernetes는 2014년 이후 채택률이 엄청나게 증가했습니다. Google의 내부 클러스터 관리 솔루션인 Borg에서 영감을 받은 Kubernetes는 애플리케이션 배포 및 관리를 간소화합니다. 모든 컨테이너 오케스트레이션 소프트웨어 와 마찬가지로 Kubernetes는 안전하고 간단하기 때문에 IT 전문가들 사이에서 인기를 얻고 있습니다. 그러나 모든 도구와 마찬가지로 아키텍처가 도구를 보다 효과적으로 사용하는 데 어떻게 도움이 되는지 인식합니다.

쿠버네티스 아키텍처가 무엇인지, 무엇을 하는지, 왜 중요한지부터 시작하여 쿠버네티스 아키텍처의 기초에 대해 알아봅시다.

Google은 다양한 환경에서 컨테이너화된 애플리케이션을 처리하는 적응형 Kubernetes 컨테이너 관리 시스템을 만들었습니다. 컨테이너화된 애플리케이션 배포를 자동화하고, 변경하고, 이러한 애플리케이션을 확장 및 축소하는 데 도움이 됩니다.

그러나 Kubernetes는 단순한 컨테이너 오케스트레이터가 아닙니다. 같은 방식으로 데스크톱 앱은 MacOS, Windows 또는 Linux에서 작동합니다. 이는 해당 프로그램의 클라우드 플랫폼 역할을 하기 때문에 클라우드 네이티브 애플리케이션용 운영 체제입니다.

컨테이너란 무엇입니까?

컨테이너는 애플리케이션이 런타임 환경에서 쉽게 실행될 수 있도록 애플리케이션 및 해당 종속성을 패키징하기 위한 표준 접근 방식입니다. 컨테이너를 사용하면 앱의 코드, 종속성 및 구성을 사용하기 쉬운 단일 빌딩 블록으로 패키징하여 배포 시간을 줄이고 애플리케이션 의존성을 높이는 데 필수적인 조치를 취할 수 있습니다.

기업 애플리케이션의 컨테이너 수는 관리할 수 없게 될 수 있습니다. 컨테이너를 최대한 활용하기 위해 Kubernetes는 컨테이너를 오케스트레이션하는 데 도움을 줍니다.

쿠버네티스는 무엇을 위해 사용됩니까?

Kubernetes는 컨테이너 워크로드를 실행하기 위한 매우 적응력이 뛰어나고 확장 가능한 플랫폼입니다. Kubernetes 플랫폼은 클라우드 네이티브 애플리케이션을 생성할 수 있는 환경을 제공할 뿐만 아니라 배포를 관리하고 자동화하는 데도 도움이 됩니다.

이는 애플리케이션 운영자와 개발자가 기본 컴퓨팅, 네트워크 및 스토리지 인프라를 조정하는 노력을 덜어 셀프 서비스 운영을 위한 컨테이너 중심 프로세스에만 집중할 수 있도록 하는 것을 목표로 합니다. 개발자는 또한 여러 컨테이너로 구성된 애플리케이션에 대한 더 높은 수준의 자동화와 함께 특수 배포 및 관리 절차를 생성할 수 있습니다.

Kubernetes는 모놀리식 애플리케이션, 상태 비저장 또는 상태 저장 프로그램, 마이크로서비스, 서비스, 배치 작업 및 그 사이의 모든 것을 포함하여 모든 중요한 백엔드 워크로드를 처리할 수 있습니다.

Kubernetes는 종종 다음과 같은 이점을 위해 선택됩니다.

• Kubernetes의 인프라는 많은 DevOps 기술의 인프라보다 우수합니다.
• Kubernetes는 정확한 관리를 위해 컨테이너를 더 작은 구성 요소로 나눕니다.
• Kubernetes는 소프트웨어 업데이트를 신속하고 정기적으로 배포합니다.
• Kubernetes는 클라우드 네이티브 앱 개발을 위한 플랫폼을 제공합니다.

Kubernetes 아키텍처 및 구성 요소

기본 Kubernetes 아키텍처는 K8s 구성 요소라고도 하는 많은 구성 요소로 구성되어 있으므로 바로 시작하기 전에 다음 개념을 기억하는 것이 중요합니다.

• 기본 Kubernetes 아키텍처는 노드를 관리하는 컨트롤 플레인과 컨테이너화된 앱을 실행하는 작업자 노드로 구성됩니다.
• 컨트롤 플레인이 실행 및 통신을 관리하는 동안 작업자 노드는 실제로 이러한 컨테이너를 실행합니다.
• Kubernetes 클러스터는 노드 그룹이며 각 클러스터에는 하나 이상의 작업자 노드가 있습니다.

Kubernetes 아키텍처 다이어그램

쿠버네티스 컨트롤 플레인

컨트롤 플레인은 클러스터의 제어 구성 요소를 수용하는 Kubernetes 클러스터 설계의 중추 신경계 센터입니다. 또한 클러스터에 있는 모든 Kubernetes 개체의 구성 및 상태를 기록합니다.

Kubernetes 컨트롤 플레인은 컴퓨팅 유닛과 정기적인 통신을 유지하여 클러스터가 예상대로 작동하도록 합니다. 컨트롤러는 개체 상태를 감독하고 클러스터 변경에 대한 응답으로 원하는 상태 또는 사양에 맞게 시스템 개체의 물리적, 관찰된 상태 또는 현재 상태를 만듭니다.

컨트롤 플레인은 API(애플리케이션 프로그래밍 인터페이스) 서버, 스케줄러, 컨트롤러 관리자 등 몇 가지 필수 요소로 구성됩니다. 이러한 기본 Kubernetes 구성 요소는 컨테이너가 적절한 리소스로 실행되도록 보장합니다. 이러한 구성 요소는 모두 단일 기본 노드에서 작동할 수 있지만 많은 회사에서 고가용성을 위해 여러 노드에 복제합니다.

1. 쿠버네티스 API 서버

Kubernetes API 서버는 Kubernetes 컨트롤 플레인의 프런트 엔드입니다. 다양한 애플리케이션에 대한 API 관리를 제공하여 업데이트, 확장, 데이터 구성 및 기타 유형의 수명 주기 오케스트레이션을 용이하게 합니다. API 서버는 게이트웨이이기 때문에 사용자는 클러스터 외부에서 액세스할 수 있어야 합니다. 이 경우 API 서버는 포드, 서비스 및 노드에 대한 터널입니다. 사용자는 API 서버를 통해 인증합니다.

2. 쿠버네티스 스케줄러

kube-scheduler는 각 컴퓨팅 노드에 대한 리소스 활용 통계를 기록하고, 클러스터가 정상인지 평가하고, 새 컨테이너를 배포할지 여부와 배포 위치를 결정합니다. 스케줄러는 중앙 처리 장치(CPU) 또는 메모리와 같은 클러스터의 전반적인 상태와 Pod의 리소스 요구를 평가합니다. 그런 다음 적절한 컴퓨팅 노드를 선택하고 리소스 제약 또는 보증, 데이터 지역성, 서비스 품질 요구 사항, 반선호도 또는 선호도 표준을 고려하여 작업, 포드 또는 서비스를 예약합니다.

3. 쿠버네티스 컨트롤러 매니저

Kubernetes 환경에서는 여러 컨트롤러가 엔드포인트(포드 및 서비스), 토큰 및 서비스 계정(네임스페이스), 노드 및 복제(자동 확장)의 상태를 관리합니다. 클라우드 컨트롤러 관리자 또는 컨트롤러라고도 하는 kube-controller 관리자는 다양한 컨트롤러 작업을 수행하여 Kubernetes 클러스터를 관리하는 데몬입니다.

컨트롤러는 Kubernetes 핵심 제어 루프를 실행하는 동안 클러스터의 객체를 모니터링합니다. API 서버를 통해 원하는 상태와 기존 상태를 모니터링합니다. 관리 개체의 현재 상태와 의도한 상태가 일치하지 않으면 컨트롤러는 개체 상태를 원하는 상태에 더 가깝게 이동하기 위해 수정 조치를 취합니다. Kubernetes 컨트롤러는 필수 수명 주기 작업도 처리합니다.

4. 기타

etcd는 구성 데이터 및 클러스터 상태 정보를 유지하는 분산된 내결함성 키-값 저장소 데이터베이스입니다. etcd는 독립적으로 설정할 수 있지만 종종 Kubernetes 제어 영역의 일부로 사용됩니다.

raft 합의 알고리즘은 etcd에서 클러스터 상태를 유지하는 데 사용됩니다. 이것은 복제된 상태 시스템의 맥락에서 일반적인 문제를 처리하는 데 도움이 되며 많은 서버가 값에 동의해야 합니다. Raft는 리더(leader), 후보(candidate), 팔로워(follower)의 세 가지 역할을 설정하고 리더 투표를 통해 합의를 도출합니다.

결과적으로 etcd는 모든 Kubernetes 클러스터 구성 요소에 대한 SSOT(Single Source of Truth)로서 컨트롤 플레인 쿼리에 응답하고 컨테이너, 노드 및 포드의 상태에 대한 다양한 정보를 수집합니다. etcd는 ConfigMaps, 서브넷, 암호 및 클러스터 상태 데이터와 같은 구성 정보를 저장하는 데에도 사용됩니다.

Kubernetes 작업자 노드

작업자 노드는 컨트롤 플레인이 관리하는 컨테이너를 실행하는 시스템입니다. 핵심 Kubernetes 컨트롤러인 kubelet은 컨트롤 플레인과 상호 작용하기 위한 에이전트로 각 노드에서 실행됩니다. 또한 각 노드는 Docker 또는 rkt와 같은 컨테이너 런타임 엔진을 실행합니다. 모니터링, 로깅, 서비스 검색 및 추가 옵션을 위한 기타 구성 요소도 노드에서 실행됩니다.

몇 가지 주요 Kubernetes 클러스터 아키텍처 구성 요소는 다음과 같습니다.

노드

Kubernetes 클러스터에는 하나 이상의 컴퓨팅 노드가 있어야 하지만 용량 요구 사항에 따라 더 많은 컴퓨팅 노드가 있을 수 있습니다. 포드는 노드에서 실행되도록 조정되고 예약되기 때문에 클러스터 용량을 늘리려면 추가 노드가 필요합니다. 노드는 Kubernetes 클러스터의 작업을 수행합니다. 애플리케이션은 물론 네트워킹, 계산 및 스토리지 리소스를 연결합니다.

데이터 센터의 노드는 클라우드 네이티브 VM(가상 머신) 또는 베어메탈 서버일 수 있습니다.

컨테이너 런타임 엔진

각 컴퓨팅 노드는 컨테이너 런타임 엔진을 사용하여 컨테이너 수명 주기를 운영하고 관리합니다. Kubernetes는 Docker, CRI-O 및 rkt와 같은 개방형 컨테이너 이니셔티브 호환 런타임을 지원합니다.

Kubelet 서비스

kubelet은 각 컴퓨팅 노드에 포함됩니다. Pod의 컨테이너가 작동하는지 확인하기 위해 컨트롤 플레인과 통신하는 에이전트입니다. 컨트롤 플레인이 노드에서 특정 작업을 수행하도록 요구하면 kubelet은 API 서버를 통해 포드 사양을 가져와 작동합니다. 그런 다음 관련 컨테이너가 제대로 작동하는지 확인합니다.

Kube 프록시 서비스

각 컴퓨팅 노드에는 Kubernetes 네트워킹 서비스를 지원하는 kube-proxy라는 네트워크 프록시가 있습니다. 클러스터 내부 및 외부의 네트워크 연결을 관리하기 위해 kube-proxy는 트래픽을 전달하거나 운영 체제의 패킷 필터링 계층에 의존합니다.

kube-proxy 프로세스는 각 노드에서 작동하여 다른 당사자가 서비스를 사용할 수 있도록 하고 특정 호스트 서브넷에 대처합니다. 노드에서 네트워크 프록시 및 서비스 로드 밸런서 역할을 하여 UDP(사용자 데이터그램 프로토콜) 및 TCP(전송 제어 프로토콜) 트래픽에 대한 네트워크 라우팅을 처리합니다. 실제로 kube-proxy는 모든 서비스 엔드포인트에 대한 트래픽을 라우팅합니다.

포드

지금까지 내부 및 인프라 관련 아이디어를 다루었습니다. 그러나 팟(Pod)은 개발자가 상호 작용하는 주요 외부 구성 요소이기 때문에 Kubernetes에 매우 중요합니다.

포드는 애플리케이션의 단일 인스턴스를 나타내는 Kubernetes 컨테이너 모델에서 가장 간단한 단위입니다. 각 팟(Pod)은 하나의 컨테이너 또는 논리적으로 서로 맞고 컨테이너의 기능을 제어하는 ​​규칙을 수행하는 밀접하게 관련된 여러 컨테이너로 구성됩니다.

Pod의 수명은 한정되어 있으며 업그레이드되거나 다시 축소된 후에는 궁극적으로 죽습니다. 일시적이지만 영구 스토리지에 연결하여 상태 저장 애플리케이션을 실행합니다.

Pod는 수평으로 확장될 수도 있습니다. 즉, 작동하는 인스턴스의 수를 늘리거나 줄일 수 있습니다. 또한 롤링 업데이트 및 카나리아 배포를 수행할 수 있습니다.

포드는 노드에서 함께 작동하므로 콘텐츠와 스토리지를 공유하고 localhost를 통해 다른 포드와 통신할 수 있습니다. 컨테이너는 여러 컴퓨터에 걸쳐 있을 수 있으며 포드도 마찬가지입니다. 단일 노드는 각각 수많은 컨테이너를 수집하는 여러 포드를 운영할 수 있습니다.

Pod는 Kubernetes 에코시스템의 중앙 관리 단위로, 리소스와 컨텍스트를 공유하는 컨테이너의 논리적 경계 역할을 합니다. 여러 종속 프로세스가 동시에 작동하도록 하는 포드 그룹화 방법은 가상화와 컨테이너화 간의 차이를 완화합니다.

기타 Kubernetes 아키텍처 구성요소

Kubernetes는 애플리케이션의 컨테이너를 유지하지만 클러스터에서 연결된 애플리케이션 데이터를 관리할 수도 있습니다. Kubernetes 사용자는 기본 스토리지 인프라를 이해하지 않고도 스토리지 리소스를 요청할 수 있습니다.

Kubernetes 볼륨은 Pod가 데이터에 액세스하고 저장할 수 있는 디렉터리입니다. 볼륨 유형은 볼륨의 내용, 생성 방법 및 이를 지원하는 미디어를 결정합니다. 영구 볼륨(PV)은 종종 관리자가 제공하는 클러스터별 스토리지 리소스입니다. PV는 지정된 포드보다 오래 지속될 수도 있습니다.

Kubernetes는 컨테이너 레지스트리 에 저장된 컨테이너 이미지 에 의존합니다. 타사 등록일 수도 있고 조직에서 만든 등록일 수도 있습니다.

네임스페이스는 물리적 클러스터 내에 존재하는 가상 클러스터입니다. 수많은 사용자와 팀을 위한 독립적인 작업 환경을 만들도록 설계되었습니다. 또한 액세스할 수 있는 Kubernetes 개체를 제한하여 팀이 서로 간섭하지 않도록 합니다. Pod 내의 Kubernetes 컨테이너는 localhost를 통해 다른 Pod와 통신하고 IP 주소와 네트워크 네임스페이스를 공유할 수 있습니다.

Kubernetes 대 Docker Swarm

Kubernetes와 Docker는 모두 컨테이너 관리 및 애플리케이션 확장을 제공하는 플랫폼입니다. Kubernetes는 설정이 복잡한 수요가 많은 애플리케이션에 이상적인 효과적인 컨테이너 관리 솔루션을 제공합니다. 반면 Docker Swarm은 단순성을 위해 구축되어 배포 및 유지 관리가 빠른 필수 앱에 탁월한 선택입니다.

• Docker Swarm은 Kubernetes보다 배포 및 구성이 더 쉽습니다.
• Kubernetes는 트래픽을 기반으로 한 올인원 확장성을 제공하는 반면 Docker Swarm은 빠른 확장을 우선시합니다.
• 자동 로드 밸런싱은 Docker Swarm에서 사용할 수 있지만 Kubernetes에서는 사용할 수 없습니다. 그러나 타사 솔루션은 외부 로드 밸런서를 Kubernetes에 연결할 수 있습니다.

회사의 요구 사항에 따라 올바른 도구가 결정됩니다.

컨테이너 오케스트레이션 솔루션

컨테이너 오케스트레이션 시스템을 통해 개발자는 애플리케이션 배포를 위해 여러 컨테이너를 시작할 수 있습니다. IT 관리자는 이러한 플랫폼을 사용하여 인스턴스 관리, 호스트 소싱 및 컨테이너 연결을 자동화할 수 있습니다.

다음은 배포를 용이하게 하고 실패한 컨테이너 구현을 식별하며 애플리케이션 구성을 관리하는 몇 가지 최고의 컨테이너 오케스트레이션 도구입니다.

Kubernetes 아키텍처 모범 사례 및 설계 원칙

보안, 거버넌스, 모니터링, 스토리지, 네트워킹, 컨테이너 라이프사이클 관리 및 오케스트레이션을 고려한 플랫폼 전략을 구현하는 것이 중요합니다. 그러나 Kubernetes는 특히 온프레미스 및 퍼블릭 클라우드 인프라를 모두 관리하는 기업의 경우 채택하고 확장하기가 매우 어렵습니다. 이를 단순화하기 위해 Kubernetes 클러스터를 설계하는 동안 고려해야 하는 몇 가지 모범 사례가 아래에 설명되어 있습니다.

• 항상 최신 버전 의 Kubernetes가 있는지 확인하십시오.
• 개발 및 운영 팀을 위한 교육에 투자하십시오 .
• 전사적 거버넌스 확립 . 도구 및 공급자가 Kubernetes 오케스트레이션과 호환되는지 확인하십시오.
• CI/CD(지속적인 통합 및 제공) 워크플로우에 이미지 스캔 기술을 포함하여 보안을 강화하십시오 . GitHub 리포지토리에서 다운로드한 오픈 소스 코드는 항상 주의해서 다루어야 합니다.
• 클러스터 전체에 RBAC( 역할 기반 액세스 제어 )를 구현합니다. 최소 권한과 제로 트러스트를 기반으로 하는 모델이 표준이 되어야 합니다.
• 루트가 아닌 사용자 만 활용하고 파일 시스템을 읽기 전용으로 만들어 컨테이너를 추가로 보호하십시오.
• 간단한 선언은 오류가 덜 발생하고 목적을 더 잘 전달하므로 기본값을 피하십시오 .
• 기본 Docker Hub 이미지를 사용할 때 맬웨어가 포함되어 있거나 불필요한 코드로 커질 수 있으므로 주의하십시오. 간결하고 깨끗한 코드 로 시작하여 작업을 진행하십시오. 작은 사진은 더 빨리 커지고 저장 공간을 덜 차지하며 이미지를 더 빨리 가져옵니다.
• 용기를 가능한 한 단순 하게 유지하십시오. 컨테이너당 하나의 프로세스를 통해 오케스트레이터는 해당 프로세스의 정상 여부를 보고할 수 있습니다.
• 의심스러운 경우 충돌이 발생합니다 . Kubernetes가 실패한 컨테이너를 다시 시작하므로 실패 시 다시 시작하지 마십시오.
• 설명적 이어야 합니다. 설명 레이블은 현재와 미래의 개발자에게 도움이 됩니다.
• 마이크로서비스에 관해서는 너무 구체적이지 마십시오 . 논리 코드 구성 요소 내의 모든 기능은 해당 마이크로 서비스가 아니어야 합니다.
• 가능한 경우 . CI/CD 워크플로를 자동화하여 수동 Kubernetes 배포를 모두 건너뛸 수 있습니다.
• 활성화 및 준비 프로브를 사용하여 포드 수명 주기 관리를 지원합니다. 그렇지 않으면 포드가 준비되기 전에 사용자 요청을 초기화하거나 수신하는 동안 포드가 종료될 수 있습니다.

컨테이너 고려

컨테이너 중심 관리 소프트웨어인 Kubernetes는 기업 내에서 컨테이너의 광범위한 사용으로 인해 컨테이너화된 애플리케이션을 배포하고 운영하기 위한 사실상의 표준이 되었습니다. Kubernetes 아키텍처는 간단하고 직관적입니다. IT 관리자가 인프라 및 애플리케이션 성능을 더 잘 제어할 수 있지만 기술을 최대한 활용하는 방법을 배워야 합니다.

주제를 더 탐구하고 싶습니까? 클라우드 컴퓨팅에서 컨테이너화의 증가하는 관련성에 대해 알아보십시오!