1. Introduction to Kubernetes and OpenShift

개요

• 목표 : 주요 Kubernetes 클러스터 서비스와 OpenShift 플랫폼 서비스를 식별하고 웹 콘솔을 사용하여 이를 모니터링합니다.
• 내용 :
  • 컨테이너 및 쿠버네티스(및 매칭 퀴즈)
  • 레드햇 오픈시프트 구성 요소 및 에디션(및 매칭 퀴즈)
  • OpenShift 웹 콘솔 탐색(및 가이드 연습)
  • OpenShift 클러스터 모니터링(및 가이드 연습)

Containers and Kubernetes

목표

• 컨테이너와 쿠버네티스의 주요 특징을 설명합니다.

 

Introduction to Containers and Kubernetes

Red Hat OpenShift 컨테이너 플랫폼(RHOCP)은 서버 클러스터에서 애플리케이션을 실행할 수 있는 완벽한 플랫폼입니다. OpenShift는 컨테이너와 Kubernetes와 같은 기존 기술을 기반으로 합니다. 컨테이너는 컨테이너 런타임이 있는 모든 시스템에서 실행할 수 있는 애플리케이션과 그 종속성을 패키지화하는 방법을 제공합니다.

Kubernetes는 컨테이너형 애플리케이션을 실행하는 서버 클러스터를 구축하는 데 많은 기능을 제공합니다. 그러나 Kubernetes는 완전한 솔루션을 제공하려는 의도가 아니라 시스템 관리자가 Kubernetes를 완료할 수 있도록 확장 지점을 제공합니다. OpenShift는 Kubernetes의 확장 지점을 기반으로 구축되어 완전한 플랫폼을 제공합니다.

 

Containers Overview

컨테이너는 호스트의 다른 컨테이너와 독립적으로 애플리케이션을 실행하는 프로세스입니다. 컨테이너는 애플리케이션의 모든 런타임 종속성을 포함하는 컨테이너 이미지에서 생성됩니다. 그런 다음 컨테이너는 호스트에 대한 종속성을 설치할 필요 없이, 서로 다른 컨테이너의 종속성 간의 충돌 없이 모든 호스트에서 실행될 수 있습니다.

Figure 1.1: Applications in containers versus on the host operating system

 

컨테이너는 네임스페이스 및 제어 그룹(cgroups)과 같은 리눅스 커널 기능을 사용합니다. 예를 들어, 컨테이너는 CPU 시간 할당 및 시스템 메모리와 같은 리소스 관리를 위해 cgroups를 사용합니다. 네임스페이스는 컨테이너의 프로세스와 리소스를 다른 컨테이너 및 호스트 시스템과 분리합니다.

오픈 컨테이너 이니셔티브(OCI)는 컨테이너, 컨테이너 이미지 및 컨테이너 런타임에 대한 표준을 유지합니다. 대부분의 컨테이너 엔진 구현은 OCI 사양에 맞게 설계되었기 때문에 사양에 따라 패키징된 애플리케이션은 모든 적합한 플랫폼에서 실행될 수 있습니다.

 

Kubernetes Overview

Kubernetes는 컨테이너형 애플리케이션의 배포, 관리 및 확장을 간소화하는 플랫폼입니다.

podman과 같은 도구를 사용하여 모든 리눅스 시스템에서 컨테이너를 실행할 수 있습니다. 예를 들어 클러스터 간에 중복성을 위해 실행할 수 있는 컨테이너화된 서비스를 만들려면 추가 작업이 필요합니다.

Kubernetes는 여러 노드에서 애플리케이션을 실행하는 클러스터를 만듭니다. 노드에 장애가 발생하면 Kubernetes는 다른 노드에서 애플리케이션을 재시작할 수 있습니다.

Kubernetes는 선언적 구성 모델을 사용합니다. Kubernetes 관리자는 클러스터에서 실행할 워크로드의 정의를 작성하며, Kubernetes는 실행 중인 워크로드가 정의와 일치하도록 보장합니다. 예를 들어, 관리자는 여러 워크로드를 정의합니다. 각 워크로드는 필요한 메모리의 양을 정의합니다. 그런 다음 Kubernetes는 메모리 요구 사항을 충족하기 위해 서로 다른 노드에 필요한 컨테이너를 생성합니다.

Kubernetes는 워크로드를 포드의 관점에서 정의합니다. 포드는 동일한 클러스터 노드에서 실행되는 하나 이상의 컨테이너입니다. 여러 컨테이너가 있는 포드는 동일한 클러스터 노드에서 두 개의 컨테이너가 실행되어 리소스를 공유해야 하는 특정 상황에서 유용합니다. 예를 들어, 작업은 완료될 때까지 포드에서 작업을 실행하는 워크로드입니다.

 

 

Kubernetes Features

Kubernetes는 컨테이너 인프라 위에 다음과 같은 기능을 제공합니다:

 

Service discovery and load balancing

여러 노드에 애플리케이션을 배포하면 애플리케이션 간의 통신이 복잡해질 수 있습니다.
Kubernetes는 자동으로 네트워킹을 구성하고 Pod에 DNS 서비스를 제공합니다. 이러한 기능을 통해 Pod는 IP 주소 대신 호스트 이름만 사용하여 노드 전반에 걸쳐 다른 Pod의 서비스와 투명하게 통신할 수 있습니다. 여러 Pod가 성능과 신뢰성을 위해 서비스를 백업할 수 있습니다. 예를 들어, Kubernetes는 NGINX Pod의 가용성을 고려하여 들어오는 요청을 NGINX 웹 서버로 균등하게 분할할 수 있습니다.

 

Horizontal scaling

Kubernetes는 서비스의 부하를 모니터링하고, 부하에 적응하기 위해 Pod를 만들거나 삭제할 수 있습니다. 일부 구성을 통해 Kubernetes는 클러스터 부하를 수용하기 위해 노드를 동적으로 프로비저닝할 수도 있습니다.

 

Self-healing

애플리케이션이 상태 확인 절차를 선언하면, Kubernetes는 실패하거나 사용할 수 없는 애플리케이션을 모니터링하고, 재시작하고, 일정을 변경할 수 있습니다. 자가 치유는 애플리케이션을 내부 장애(애플리케이션이 예기치 않게 중지됨)나 외부 장애(애플리케이션을 실행하는 노드가 사용할 수 없게 됨)로부터 보호합니다.

 

Automated rollout

Kubernetes는 애플리케이션 컨테이너에 대한 업데이트를 점진적으로 롤아웃할 수 있습니다. 롤아웃 중에 문제가 발생하면 Kubernetes는 이전 버전의 배포로 롤백할 수 있습니다. Kubernetes는 롤아웃된 애플리케이션 버전으로 요청을 라우팅하고 롤아웃이 완료되면 이전 버전에서 Pod를 삭제합니다.

 

Secrets and configuration management

컨테이너를 변경할 필요 없이 애플리케이션의 구성 설정과 secret을 관리할 수 있습니다. Application secrets은 usernames, passwords, 그리고 service endpoints 또는 비공개로 유지해야 하는 모든 구성 설정일 수 있습니다.

 

Operators

운영자는 선언적인 방식으로 Kubernetes 워크로드를 관리할 수 있는 Kubernetes 애플리케이션으로 패키징되어 있습니다. 예를 들어, 운영자는 데이터베이스 서버 리소스를 정의할 수 있습니다. 사용자가 데이터베이스 리소스를 만들면 운영자는 데이터베이스 배포, 복제 구성 및 자동 백업에 필요한 워크로드를 생성합니다.

 

 

Kubernetes Architectural Concepts

Kubernetes는 관리하는 애플리케이션의 복원력과 확장성을 보장하기 위해 여러 서버(노드라고도 함)를 사용합니다. 이러한 노드는 물리적 또는 가상 머신일 수 있습니다. 노드는 두 가지 유형으로 제공되며, 각 유형은 클러스터 작업의 다른 측면을 제공합니다.

Control plane  노드는 배포된 워크로드를 스케줄링하기 위한 전역 클러스터 조정 기능을 제공합니다. 또한 이러한 노드는 클러스터 이벤트 및 요청에 대한 응답으로 클러스터 구성의 상태를 관리합니다.

 

Compute plane 노드는 사용자 워크로드를 실행합니다.

 

Figure 1.2: Kubernetes components

 

서버는 제어 Control plane 노드와 Compute plane 노드로 모두 작동할 수 있지만, 안정성, 보안, 관리 용이성을 높이기 위해 두 가지 역할이 일반적으로 분리되어 있습니다. Kubernetes 클러스터는 작은 단일 노드 클러스터부터 최대 5,000개의 노드를 가진 대규모 클러스터까지 다양합니다.

 

The Kubernetes API and Configuration Model

Kubernetes는 클러스터에 워크로드를 정의할 모델을 제공합니다. 관리자는 리소스 측면에서 워크로드를 정의합니다.

모든 리소스 유형이 동일한 방식으로 작동하며, 균일한 API를 사용합니다.

 

kubectl 명령어와 같은 도구는 모든 유형의 리소스, 심지어 사용자 지정 리소스 유형도 관리할 수 있습니다.

Kubernetes는 텍스트 파일로 리소스를 가져오고 내보낼 수 있습니다. 관리자는 텍스트 형식의 리소스 정의를 사용하여 올바른 작업 순서를 수행하는 대신 워크로드를 설명할 수 있습니다. 이 접근 방식을 선언적 리소스 관리라고 합니다.

 

Figure 1.3: Declarative resource management

 

선언적 리소스 관리는 워크로드 생성 작업을 줄이고 유지보수성을 향상시킬 수 있습니다. 또한 텍스트 파일을 사용하여 리소스를 설명할 때 관리자는 버전 관리 시스템과 같은 일반적인 도구를 사용하여 변경 추적과 같은 추가적인 이점을 얻을 수 있습니다.

선언적 리소스 관리를 지원하기 위해 Kubernetes는 클러스터의 상태를 지속적으로 추적하고 클러스터를 의도된 상태로 유지하는 데 필요한 단계를 수행하는 controllers를 사용합니다. 이 프로세스는 리소스를 변경하는 데 종종 시간이 필요하다는 것을 의미합니다. 그러나 Kubernetes는 복잡한 변경 사항을 자동으로 적용할 수 있습니다. 예를 들어 현재 노드에서 만족할 수 없는 애플리케이션의 RAM 요구 사항을 늘리면 Kubernetes는 충분한 RAM이 있는 노드로 애플리케이션을 이동할 수 있습니다. Kubernetes는 이동이 완료된 경우에만 트래픽을 새 인스턴스로 리디렉션합니다.

Kubernetes는 네임스페이스도 지원합니다. 관리자는 네임스페이스를 만들 수 있으며, 대부분의 리소스는 네임스페이스 내부에서 생성되어야 합니다. 네임스페이스는 대량의 리소스를 정리하는 데 도움을 줄 뿐만 아니라 리소스 접근과 같은 기능의 기초를 제공합니다. 관리자는 네임스페이스에 대한 권한을 정의하여 특정 사용자가 리소스를 보거나 수정할 수 있도록 할 수 있습니다.