Kubernetes 필요이유 , Kubernetes란 무엇인가? 쿠버네티스란? k8s?,Docker? -1

 

Contents

---

 

 

 

'쿠버네티스 인 액션' 을보고 정리한 내용입니다.

쿠버네티스(kubernetes)k8s 필요이유?

오늘날 이러한 대규모 모놀리식 레거시 애플리케이션은 마이크로서비스라고 하는 더 작고 독립적으로 실행되는 구성 요소로 서서히 세분화되고 있습니다.

왜냐하면 마이크로서비스는 서로 분리되어 개별적으로 개발, 배포, 업데이트 및 확장할 수 있습니다. 이를 통해 구성 요소를 신속하게 그리고 필요한 만큼 자주 변경하여 오늘날의 급변하는 비즈니스 요구 사항을 따라잡을 수 있습니다.그러나 배포 가능한 구성 요소의 수가 증가하고 데이터 센터가 점점 더 커지면서 전체 시스템을 구성, 관리 및 원활하게 실행하는 것이 점점 더 어려워지고 있습니다. 높은 리소스 활용도를 달성하고 하드웨어 비용을 낮추기 위해 각 구성 요소를 어디에 배치해야 하는지 파악하는 것은 훨씬 더 어렵습니다. 이 모든 작업을 수동으로 수행하는 것은 어려운 작업입니다. 이러한 구성 요소를 서버에 자동으로 예약하고, 자동 구성, 감독 및 오류 처리를 포함하는 자동화가 필요합니다. 이것이 바로 쿠버네티스가 필요한 이유입니다.

 

쿠버네티스란(k8s) 무엇인가?

Kubernetes는 하드웨어 인프라를 추상화하고 전체 데이터 센터를 하나의 거대한 컴퓨팅 리소스로 노출합니다. 그러므로 실제 서버에 대해 알 필요 없이 소프트웨어 구성 요소를 배포하고 실행할 수 있습니다. 쿠버네티스를 통해 다중 컴포넌트 애플리케이션을 배포할 때, 쿠버네티스는 각 컴포넌트에 대한 서버를 선택하고, 배포하며, 애플리케이션의 다른 모든 컴포넌트를 쉽게 찾고 통신할 수 있도록 합니다.

 

쿠버네티스 등장 배경

기존 모놀리식 애플리케이션은 모두 긴밀하게 결합된 구성 요소로 구성되며, 모두 단일 OS 프로세스로 실행되기 때문에 하나의 엔터티로 개발, 배포 및 관리해야 합니다. 응용 프로그램의 한 부분을 변경하려면 전체 응용 프로그램을 다시 배포해야 하며, 시간이 지남에 따라 부분 간에 엄격한 경계가 없으면 이러한 부분 간의 상호 종속성이 제한 없이 증가하기 때문에 복잡성이 증가하고 결과적으로 전체 시스템의 품질이 저하됩니다.

이러한 문제로 인해 복잡한 모놀리식 애플리케이션을 마이크로서비스라고 하는 더 작고 독립적으로 배포 가능한 구성 요소로 분할하기 시작했습니다. 각 마이크로 서비스는 독립적인 프로세스로 실행되며(그림 1.1 참조) 간단하고 잘 정의된 인터페이스(API)를 통해 다른 마이크로 서비스와 통신합니다.이렇게 작은 독립적인 서버들을 관리하기위해 쿠버네티스가 등장 했습니다.

 

 

쿠버네티스와 컨테이너

쿠버네티스는 리눅스 컨테이너 기술을 사용하여 실행 중인 애플리케이션을 격리하므로, 쿠버네티스 자체를 파헤치기 전에 쿠버네티스가 자체적으로 수행하는 작업과 Docker 또는 rkt("rock-it"으로 발음)와 같은 컨테이너 기술로 오프로드하는 것을 이해하기 위해 컨테이너의 기본 사항을 숙지해야 합니다.

 

Docker 컨테이너 플랫폼 소개

애플리케이션을 패키징, 배포 및 실행하기 위한 플랫폼입니다.

 

Docker를 이용한 배포 방법

 

 

쿠버네티스를 이용한 배포 방법

 

 

쿠버네티스 클러스터의 아키텍처 이해

마스터 노드 : 전체 쿠버네티스 시스템을 제어하고 관리하는 쿠버네티스 컨트롤 플레인을 호스팅함

작업자 노드 : 배포하는 실제 애플리케이션을 실행함

 

 

마스터 노드 (Control Plane)

컨트롤 플레인은 클러스터를 제어하고 작동하게 하는 것입니다. 단일 마스터 노드에서 실행하거나 여러 노드로 분할하고 복제하여 고가용성을 보장할 수 있는 여러 구성 요소로 구성됩니다. 이러한 구성 요소는 다음과 같습니다

 

Kubernetes API Server

사용자와 다른 컨트롤 플레인 구성 요소가 통신함

Scheduler

응용 프로그램의 배포 가능한 각 구성 요소에 작업자 노드를 할당합니다.

Controller Manager

구성 요소 복제, 작업자 노드 추적, 노드 장애 처리 등과 같은 클러스터 수준 기능을 수행합니다

etcd

클러스터 구성을 영구적으로 저장하는 신뢰할 수 있는 분산 데이터 저장소입니다.

 

작업자 노드

컨테이너화된 애플리케이션을 실행하는 시스템입니다. 응용 프로그램을 실행, 모니터링 및 서비스에 제공하는 작업은 다음 구성 요소에 의해 수행됩니다

 

Kubelet

API 서버와 통신하고 노드의 컨테이너를 관리한다

Kubernetes Service 프록시(kube-proxy)

애플리케이션 구성 요소 간에 네트워크 트래픽을 로드 밸런싱합니다.

 

What Is a Pod?

파드(Pod)는 배치되어 원자 단위를 형성하는 컨테이너의 모음이다. 파드 내에서 여러 애플리케이션이 실행될 수 있으며, 파드 내의 다른 컨테이너는 동일한 애플리케이션을 위한 것일 수 있지만, 일반적으로 다른 컨테이너는 서로 다른 애플리케이션을 위한 것이다. 파드는 공유 볼륨과 네트워크 네임스페이스가 있는 컨테이너 그룹을 관리하기 위한 더 높은 수준의 추상화이다. 파드의 모든 애플리케이션(컨테이너)은 동일한 파일 시스템과 IP 주소를 공유하며, 각 애플리케이션이 노출되는 포트는 서로 다르다. 파드에서 실행 중인 애플리케이션들은 "localhost"에서 서로 접근할 수 있다. 스케줄링 및 복제는 개별 컨테이너 수준이 아닌 Pod 수준에서 수행됩니다. 예를 들어, 파드가 서로 다른 애플리케이션에 대해 두 개의 컨테이너를 정의하고 복제 레벨이 1로 설정된 경우, 파드의 단일 복제본은 두 애플리케이션에 대해 각각 하나씩 두 개의 컨테이너로 구성된다. Pod는 리소스 공유 및 통신을 용이하게 하며, 그렇지 않으면 개별적으로 실행되는 Docker 컨테이너에서 --link를 사용하여 구현됩니다. 여러 컨테이너로 구성된 파드는 일반적으로 긴밀하게 결합된 애플리케이션에 사용된다. 예를 들어, nginx 애플리케이션이 MySQL 데이터베이스를 사용하는 경우, 두 애플리케이션은 동일한 파드에서 각각 컨테이너를 실행하는 쿠버네티스를 통해 상호 작용할 수 있다.

 

앱 디스크립터에 3개의 그룹화된 컨테이너 4개를 볼수있다 앞에 두개의 컨테이너는 각각 하나씩 그룹되어있으며, 이러한 그룹을 pod라고 부른다. 그리고 3번째 그룹화된 컨테이너에는 2개가 들어가있으며 이 2개는 함께 세트로 운영되어야 하는것을 의미한다.

 

 

What Is a Service?

서비스는 하나 이상의 파드에 대한 외부 인터페이스로, 서비스가 나타내는 애플리케이션을 호출할 수 있는 엔드포인트를 제공한다. 서비스는 단일 IP 주소에서 호스팅되지만 서비스에서 상호 작용하는 응용 프로그램에 따라 0개 이상의 endpoint 을 제공합니다. 서비스는 레이블 선택기를 사용하여 파드에 연결된다. 파드에는 레이블이 있으며, 파드 레이블과 동일한 선택기 표현식이 있는 서비스는 외부 클라이언트에 파드를 나타낸다. 외부 클라이언트는 서비스로 표현되는 파드에 대해 알지 못하거나 알 필요가 없다. 외부 클라이언트는 서비스의 이름과 특정 응용 프로그램이 노출되는 포트만 알면 됩니다. 서비스는 라운드로빈 방식을 기반으로 애플리케이션에 대한 요청을 레이블 선택기/를 사용하여 선택된 파드 중 하나로 라우팅한다. 따라서 서비스는 어떤 파드가 요청을 서비스까지 라우팅할 것인지에 대한 세부 정보를 남기는 애플리케이션 모음에 대한 높은 수준의 추상화이다. 서비스는 부하 분산에도 사용할 수 있습니다.

 

What Is a Replication Controller?

리플리케이션 컨트롤러는 리플리케이션 컨트롤러 정의의 "replicas" 설정 또는 –replicas 파라미터를 사용하여 커맨드 라인에 지정된 대로 파드의 리플리케이션 레벨을 관리한다. 복제 컨트롤러는 구성된 수준의 Pod 복제본이 지정된 시간에 실행되도록 합니다. 복제본이 실패하거나 의도적으로 중지되면 새 복제본이 자동으로 시작됩니다. 리플리케이션 컨트롤러(Replication Controller) 는 클러스터 내에서 파드를 스케일링하는 데 사용된다. 복제본은 파드 레벨에서 정의되며, 이는 파드가 두 개의 컨테이너로 구성된 경우 구성된 두 컨테이너의 그룹이 레플리카를 구성한다는 것을 의미한다.

 

 

What Is a Label?

Label은 파드, 서비스, 리플리케이션 컨트롤러와 같은 리소스를 식별하는 키-값 쌍으로, 가장 일반적으로 파드이다. Label은 서비스에 할당하는 것과 같은 작업을 위해 리소스 그룹 또는 하위 집합을 식별하는 데 사용됩니다. 서비스는 레이블 선택기를 사용하여 관리하는 파드를 선택한다. 예를 들어, 파드에 "app = helloApp"이라는 라벨이 붙고 서비스 "selector"가 "app = helloApp"으로 설정된 경우, 파드는 서비스로 표현된다. 서비스 선택기는 관리하는 응용 프로그램 유형이 아닌 레이블을 기반으로 합니다. 예를 들어, 서비스는 특정 레이블이 있는 hello-world 애플리케이션 컨테이너를 실행하는 파드를 나타낼 수 있다. hello-world 컨테이너를 실행하지만 서비스 선택기 표현식과 다른 레이블을 가진 다른 파드는 서비스로 표현되지 않는다. 그리고 hello-world 애플리케이션은 아니지만 서비스 셀렉터와 동일한 레이블을 가진 애플리케이션을 실행하는 세 번째 파드도 동일한 서비스로 표현된다.

 

What Is a Selector?

선택기는 일치하는 레이블을 사용하여 리소스를 식별하는 키-값 표현식입니다. 앞의 서브섹션에서 논의한 바와 같이, 서비스 셀렉터 표현식 "app = helloApp"은 "app = helloApp" 레이블이 있는 모든 파드를 선택한다. 일반적으로 서비스는 파드를 선택하기 위해 셀렉터를 정의하지만, 서비스는 셀렉터를 포함하지 않고 다른 종류의 백엔드를 추상화하도록 정의될 수 있다. 두 가지 종류의 선택기(같음 기반 및 집합 기반)가 지원됩니다. 선택기는 ','로 구분된 여러 식(같음 기반 또는 집합 기반)을 지정할 수 있음을 암시하는 여러 요구 사항으로 구성될 수 있습니다. 모든 요구 사항은 리소스를 선택하기 위해 Pod와 같은 일치하는 리소스에 의해 충족되어야 합니다. 파드와 같은 리소스에는 추가 레이블이 있을 수 있지만, 선택하기 위해서는 선택기의 레이블을 지정해야 한다. 더 일반적으로 사용되며 책에서 사용되는 같음 기반 선택기는 =,!=,== 연산자를 지원하며 =는 ==와 동의어입니다.