Kubernetes 컨설팅에 대한 블로그 시리즈를 시작하기에 논리적인 위치는 Kubernetes 아키텍처 자체에 대한 소개입니다. 최소한 그것이 시작하기에 자연스러운 장소라고 가정해야 합니다! 사실, 이것은 이 시리즈의 10번째(셀 수 없었습니다…?) 게시물입니다.
그러나 결코 늦지 않는 것보다 낫습니다. Kubernetes에 대한 이 기본 소개는 컨테이너 오케스트레이션 기술에 대한 IBM의 놀랍도록 간단하고 간결한 설명을 기반으로 합니다.
Kubernetes는 컨테이너 기반 워크로드를 실행하고 관리할 수 있는 오케스트레이션 도구입니다. 설명을 위해 관리형 Kubernetes 서비스의 참조 아키텍처를 살펴보겠습니다. 또한 Kubernetes 아키텍처에 마이크로서비스를 배포하는 방법에 대해 조금 더 자세히 살펴보겠습니다.
개인의 필요에 따라!
Kubernetes 아키텍처는 두 가지 측면으로 나눌 수 있습니다.
- K8s의 클라우드 관리 사이트
- K8s의 고객 관리 페이지
Kubernetes 아키텍처의 클라우드 측에서 가장 중요한 구성 요소는 K8 마스터 또는 마스터 노드입니다. Kubernetes 마스터에는 API 서버가 가장 중요한 역할 중 하나를 수행하는 중요한 구성 요소가 많이 포함되어 있습니다.
마스터에서 실행되는 Kubernetes API 서버는 모든 워크로드를 실행하는 데 필수적입니다. 이러한 워크로드 실행 방법을 미세 조정할 수 있는 일련의 기능을 제공합니다.
역시 Kubernetes를 기반으로 하는 작업자 노드는 아키텍처의 고객 관리 측에 상주합니다. 각 작업자 노드에는 큐벨렛.
kubelet은 작업자 노드의 애플리케이션이 작동하도록 스케줄링하고 확인하는 역할을 합니다. 상상할 수 있듯이 이는 마스터 노드와 kubelet이 함께 작동하는 경우가 많다는 것을 의미합니다.
그러나 한 걸음 물러서서 “왜 쿠버네티스를 사용하는가?”라는 근본적인 질문을 해보자.
마이크로서비스로 구성된 클라우드 네이티브 애플리케이션이 있는 경우 이러한 마이크로서비스는 네트워크를 통해 서로 통신해야 합니다. 간단한 예로 프론트엔드와 백엔드가 있다고 가정해 보겠습니다. 이 두 구성 요소는 오늘 확장 및 클러스터링될 예정입니다.
Kubernetes는 YAML을 사용하여 API 서버로 전송되는 리소스를 정의하고 최종적으로 실제 애플리케이션을 빌드합니다. 그렇다면 작업자 노드에서 간단한 컨테이너를 실행할 수 있게 해주는 작은 논리 단위인 포드를 배포하기 위한 간단한 YAML은 어떤 모습일까요?
팟(Pod)과 연관된 이미지부터 시작하겠습니다. 이것이 우리가 이미 Docker Hub에 업로드한 컨테이너라고 가정해 보겠습니다. 우리는 레지스트리를 사용하고 애플리케이션을 “fv.1.0”이라고 부릅니다.
우리는 또한 매우 중요한 레이블을 가지고 있으며 잠시 후 레이블에 대해 자세히 설명하겠습니다. 레이블을 사용하면 이것이 어떤 유형의 아티팩트인지 정확히 정의할 수 있습니다. 캡션은 “The app is f”와 같은 내용이어야 합니다.
레이블 – a:f
포드가 생성되면 프로세스를 통해 작업자 노드로 이동하려고 합니다.
이는 kubectl을 통해 달성됩니다. kubectl을 사용하여 포드의 간단한 매니페스트를 작업자 노드 중 하나에 배포합니다. 포드 매니페스트는 Kubetcl을 통해 전달되고 K8s 마스터에서 실행되는 Kubernetes API에 도달한 후 아키텍처의 고객 측에 있는 kubelet 중 하나와 통신합니다.
그런 다음 kubelet은 작업자 노드에서 포드를 시작합니다. 내부 IP 주소도 포드에 할당됩니다. 이 시점에서 작업자 노드 중 하나에 SSH로 연결하고 IP 주소를 사용하여 애플리케이션에 연결할 수 있습니다.
이렇게 하면 Kubernetes 아키텍처에 간단한 애플리케이션 배포가 완료됩니다. 한 단계 더 나아가 봅시다.
배포 및 원하는 상태
Kubernetes에는 Desired State라고 부르는 것을 생성하는 데 사용할 수 있는 배포라는 추상화가 있습니다. 포드에 대해 원하는 복제본 수를 설정할 수 있으며 해당 포드에 문제가 발생하여 실패하면 새 포드가 생성됩니다.
작업자 노드에 배포하고 이름이 app:f 인 포드로 돌아가 보겠습니다. 이 포드의 복제본을 3개 생성하려고 합니다. 우리도 원래대로 돌아가자 명백한 다시 클라우드 사이드로. Kubernetes에 알려야 할 한 가지는 포드 템플릿과 같은 포드가 필요하지 않다는 것입니다.
또한 고려해야 할 몇 가지 다른 사항이 있습니다. 복제본 수(예: 복제본 3개)를 정의해야 합니다. 우리도 하나 있어요 선택자. 이를 통해 작업자 노드에서 실행 중인 애플리케이션과 동일한 이름(app:f)을 가진 모든 애플리케이션을 관리하도록 배포에 지시합니다.
마지막으로 어떤 종류의 아티팩트(배포)를 다루고 있는지 정의해야 합니다. 새로운 매니페스트는 다음과 같습니다.
API 서버에 도달하도록 kubectl을 통해 새 매니페스트를 푸시합니다. 매니페스트는 수명이 짧은(임시) 개체가 아닙니다. 쿠버네티스에는 목표 상태 관리하다 배포가 있고 삭제되지 않은 한 마스터 노드의 Kubernetes에서 관리합니다.
이제 마스터 노드가 배포를 생성합니다. 이제 3개의 복제본이 있으므로 3개가 항상 실행되도록 합니다. 배포가 생성되면 현재 작업 노드에서 실행 중인 복제본이 하나뿐이고 두 개가 더 필요하다는 것을 알게 됩니다.
마스터 노드는 Kubernetes 아키텍처가 클라이언트 측에 리소스를 가지고 있는 곳이면 어디든 3개의 복제본에 애플리케이션을 배포할 계획입니다. 따라서 다른 두 개는 여전히 사용 가능한 빈 작업자 노드에 배치됩니다.
이제 Kubernetes 배포를 만들었습니다. 애플리케이션의 백엔드에 대해 동일한 작업을 수행해야 하는 경우 이를 위한 또 다른 애플리케이션 배포를 생성해 보겠습니다. 기본 노드에서 앱을 추가합니다. 백엔드 예를 들어 복제본 2개로 확장합니다. 이제 다음과 같은 것이 있습니다.
이제 K8 아키텍처의 클라이언트 측에 배포한 서비스 간의 통신에 대해 생각할 때입니다. 앞에서 언급했듯이 각 포드에는 IP 주소가 있습니다. 그러나 일부는 버그가 있거나 어느 시점에서 업데이트가 필요할 수 있습니다.
팟(Pod)이 사라졌다가 다시 돌아올 때 다른 IP 주소를 사용합니다. 그러나 백엔드 또는 외부 사용자로부터 이러한 포드에 액세스하려면 신뢰할 수 있는 IP 주소가 필요합니다. 이는 오랜 문제이므로 서비스 레지스트리 및 서비스 복구 기능은 이 문제를 해결하기 위해 특별히 설계되었습니다.
이러한 기능은 Kubernetes에 내장되어 있습니다. 이제 별도의 서비스가 아닌 단일 앱을 통해 Pod에 액세스할 수 있도록 보다 안정적인 IP 주소를 설정하는 서비스를 생성합니다.
다시 한 걸음 물러서서 세 개의 팟(Pod)에 대한 서비스 정의를 작성해 보겠습니다. 이를 위해 YAML에 새로운 매니페스트가 필요하며 이를 위해 파일에 새 섹션을 만듭니다. 종류: 서비스 및 앱 레이블과 일치하는 선택기를 추가해야 합니다. 마지막으로 유형이 필요합니다. 이것은 Kubernetes 클러스터 내부의 항목에 액세스할 수 있도록 클러스터 IP입니다. 결과는 다음과 같습니다.
다시 Kubectl을 통해 YAML을 배포합니다. 마스터에 도달한 다음 클라이언트 측으로 푸시되어 포드를 단일 애플리케이션으로 그룹화할 각각의 추상화를 생성합니다. 이제 서비스 간의 통신을 보장하는 데 사용할 수 있는 내부 클러스터 IP가 있습니다.
또한 일반적으로 기본적으로 실행되는 Kubernetes의 DNS 서비스를 사용하면 프런트엔드와 백엔드 또는 줄여서 f와 b라는 이름만 사용하여 서비스가 서로 더 쉽게 액세스할 수 있습니다.
이제 한 단계 더 나아가 최종 사용자가 애플리케이션의 프런트 엔드에 액세스할 수 있도록 하려면 서비스 유형을 정의해야 합니다. 이 경우 로드 밸런서가 필요합니다. 이를 달성하기 위한 노드 포트와 같은 다른 옵션이 있지만 로드 밸런서는 클러스터에 대한 외부 IP를 생성합니다.
그런 다음 이 외부 IP 주소를 최종 사용자에게 직접 전달하고 최종 사용자는 이를 사용하여 프런트 엔드에 직접 액세스할 수 있습니다.
결론
Kubernetes 아키텍처의 세 가지 주요 구성 요소에 대해 논의했습니다.
- 꼬투리
- 배포된 후 배포에 의해 관리되는 포드
- 서비스를 사용하여 이러한 배포에서 생성된 포드에 대한 액세스를 용이하게 합니다.
이들은 Kubernetes 마스터 및 작업자 노드와 함께 작동하여 원하는 방식으로 관리형 Kubernetes 서비스에 애플리케이션을 배포하기 위한 DevOps 워크플로우를 재정의할 수 있는 세 가지 주요 구성 요소입니다.