위 kubeadm join 명령어를 사용하여 Control Plane 추가 시 아래 오류가 발생하였습니다.
[download-certs] Downloading the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
secrets "kubeadm-certs" is forbidden: User "system:bootstrap:sa3r4y" cannot get resource "secrets" in API group "" in the namespace "kube-system"
error downloading the secret
오류 내용은 join 하고자하는 클러스터의 인증서 파일이 "kube-system" Namespace, "kubeadm-certs" 이름의 Secret으로 조회할 수 없어 발생한 오류입니다.
상세 내용으로는 첫 번째 Control Plane 노드를 설정한 클러스터에서 클러스터 인증서 파일이 생성 및 저장되지 않아 조회 시 발생한 오류로 kubeadm init 및 수동으로 인증서 생성 시 --upload-certs 옵션을 사용하여 인증서를 정상적으로 생성 및 저장하여 오류를 해결 할 수 있습니다.
해결 방법
노드 구성 (kubeadm init)
신규로 노드를 구성하거나 기존에 구성한 노드를 초기화 후 다시 재구성할 경우 kubeadm init 명령어 시 --upload-certs 옵션을 추가합니다. 노드가 구성되면서 인증서 파일은 정상적으로 생성 및 저장됩니다.
# kubeadm init --control-plane-endpoint "<고정 IP 또는 DNS 이름>:6443" --upload-certs ...
신규 인증서 발급
아래 명령어를 사용하여 신규 인증서를 발급하여 "kube-system" Namespace, "kubeadm-certs" 이름의 Secret에 인증서를 저장합니다.
# kubeadm init phase upload-certs --upload-certs
[upload-certs] Storing the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[upload-certs] Using certificate key:
8ff8f8c871c6bab95b42b0e1928ffbb4d935ac9355dc4484379fd648a4dc4a37
생성된 인증서의 key 값을 사용하여 다시 kubeadm join 명령어를 사용하여 새로운 노드를 추가합니다.
Kubernetes의 kubeadm join 명령어 사용 시 인증서 관련 오류를 확인해봤습니다.
인증서를 신규로 발급하여 저장하는 방법으로 간단히 오류를 해결할 수 있으며 join 시에는 다양한 오류가 발생할 수 있으니 오류 로그를 확인 후 잘 해결해보시기 바랍니다.
지금까지 새로운 노드를 클러스터의 Control Plane에 추가 시 발생한 오류 내용과 해결 방법을 알아봤습니다....! 끝...!
Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.
Kubernetes에서 Master 노드와 Worker 노드는 클러스터를 구성하는 두 가지 주요 노드 유형입니다. 각 노드는 서로 다른 역할을 가지고 있으며, 이들이 협력하여 애플리케이션을 배포하고 관리하는 환경을 제공합니다.
Master 노드와 Worker 노드의 개념에 대해서 알아보도록 하겠습니다.
개념
Master 노드
주요 : 클러스터 제어 및 관리, 작업 스케줄링 담당
Master 노드는 클러스터의 중앙 제어 시스템으로, 클러스터 상태를 관리하고, 워크로드를 스케줄링하며, Worker 노드를 관리하는 역할을 합니다. 여러 주요 컴포넌트로 구성되어 있으며, 이들 컴포넌트가 협력하여 클러스터가 안정적이고 효율적으로 작동하도록 보장합니다.
Master 노드가 다운되면 클러스터의 제어 기능에 문제가 발생하며, 특히 단일 Master 노드 구성에서는 클러스터 가용성이 크게 저하됩니다. 이 때문에 프로덕션 환경에서는 일반적으로 다중 Master 노드를 구성하여 고가용성을 보장하고, Master 노드에 문제가 발생해도 클러스터가 지속적으로 운영될 수 있도록 합니다.
Worker 노드
주요 : 애플리케이션(Pod) 실행 및 실제 작업 수행
Worker 노드는 클러스터에서 실제로 애플리케이션이 실행되는 장소로, 클러스터에 배포된 Pod와 컨테이너를 호스팅하고 관리합니다. 사용자가 요청한 애플리케이션 워크로드를 처리하고, 각 애플리케이션이 원활하게 동작하도록 필요한 리소스를 제공합니다. Kubernetes 클러스터에서 실질적인 작업을 수행하는 노드로, 모든 애플리케이션과 서비스를 실제로 실행하며, 각 Pod와 컨테이너가 배포된 상태에서 안정적으로 동작하도록 보장합니다.
구성요소
Master 노드
API 서버 (kube-apiserver)
API 서버는 Kubernetes 클러스터와 상호작용하는 주요 구성요소 입니다.
사용자가 Kubernetes 클러스터와 통신할 때, kubectl과 같은 CLI 도구 또는 외부 시스템은 API 서버를 통해 요청을 전달합니다.
모든 요청을 인증 및 인가하고, 필요한 경우 요청을 허용하거나 거부합하며 etcd에 저장된 클러스터 상태를 조회하고 업데이트하여 클러스터의 일관성을 유지합니다.
etcd
etcd는 Kubernetes 클러스터의 모든 상태 데이터를 저장하는 분산 키-값 데이터베이스입니다.
Kubernetes의 핵심 데이터 저장소로, 클러스터의 구성 정보와 상태 정보를 영구적으로 저장합니다.
모든 Kubernetes 오브젝트(Pod, 서비스, ConfigMap 등)의 상태, 구성, 설정 등을 저장합니다.
컨트롤러 매니저 (kube-controller-manager)
컨트롤러 매니저는 여러 개의 컨트롤러를 하나의 프로세스에서 관리하는 역할을 합니다.
클러스터의 상태를 지속적으로 점검하고 수정하여 원하는 상태를 유지합니다
스케줄러 (kube-scheduler)
스케줄러는 새로 생성된 Pod를 클러스터 내의 적절한 Worker 노드에 배치하는 역할을 합니다.
적절한 노드를 선택하여 리소스를 최적화하며, 클러스터의 안정성과 효율성을 높입니다.
스케줄러가 없으면, 새로운 Pod가 생성되어도 어느 노드에서도 실행되지 않습니다.
클라우드 컨트롤러 매니저 (cloud-controller-manager)
클라우드 컨트롤러 매니저는 클라우드 환경에서 Kubernetes 클러스터와 클라우드 공급자 간의 상호작용을 담당하는 컴포넌트입니다.
이는 Kubernetes와 클라우드 제공자 API 간의 인터페이스 역할을 하며 이를 통해 클러스터 관리와 확장성을 높일 수 있습니다.
Worker 노드
kubelet
kubelet은 Worker 노드의 핵심 에이전트로, 해당 노드에서 실행될 Pod와 컨테이너를 관리하는 역할을 합니다.
Master 노드의 API 서버와 지속적으로 통신하여, 노드에서 실행할 Pod의 정의를 받고 이를 관리합니다.
kubelet은 각 Pod의 상태를 주기적으로 확인하고 보고하여, 문제가 발생한 경우 자동으로 복구하거나 재시작하는 등의 작업을 수행합니다.
컨테이너 런타임(Container Runtime)
컨테이너 런타임은 컨테이너 작업 및 실행을 담당하는 소프트웨어입니다.
Kubernetes는 여러 컨테이너 런타임을 지원하며, 대표적으로 Docker, containerd, CRI-O 등이 사용됩니다.
컨테이너 런타임은 kubelet과 상호작용하여 Pod의 컨테이너를 생성, 시작, 중지하는 작업을 수행합니다.
kube-proxy
kube-proxy는 Kubernetes 클러스터 내에서 네트워크 통신을 관리하는 역할을 하는 네트워크 프록시입니다.
클러스터 내부의 모든 Pod와 서비스 간의 네트워크 트래픽을 라우팅하고, 네트워크 규칙을 설정하여 서비스와 Pod가 서로 통신할 수 있도록 지원합니다.
구성 요소를 보면 Kubernetes는 Master 노드와 Worker 노드로 역할이 분리되어 클러스터를 안정적으로 관리하고 확장성을 높이는 특징이 있습니다. Master 노드는 클러스터의 상태 관리, 스케줄링, 클라우드 연동을 담당하고, Worker 노드는 kubelet, 컨테이너 런타임 등을 통해 실제 애플리케이션을 실행합니다. 이러한 구조는 Kubernetes가 다양한 환경에서 유연하고 효율적으로 작동하도록 지원합니다.
Kubernetes에서 Master 노드와 Worker 노드의 개념과 구성을 간단히 알아봤는데요.
먼저, Kubernetes 클러스터를 구성하기 위해 Master 노드와 Worker 노드의 역할을 이해해야 합니다.
Master 노드는 클러스터의 상태 관리, 작업 스케줄링, 클라우드 연동을 담당하는 중앙 제어 시스템으로, API 서버, etcd, 컨트롤러 매니저, 스케줄러 등으로 구성됩니다. Worker 노드는 실제 애플리케이션이 실행되는 작업 노드로, kubelet, 컨테이너 런타임, kube-proxy 등의 구성 요소를 포함해 Pod와 컨테이너를 관리합니다.
구성 요소를 보면 Kubernetes는 Master 노드와 Worker 노드로 역할이 분리되어 있으며, 클러스터의 안정성과 확장성을 높이는 구조로 설계되었습니다. 이를 통해 다양한 환경에서 유연하고 효율적인 애플리케이션 배포 및 관리가 가능합니다.
지금까지 Kubernetes에서 Master 노드와 Worker 노드의 개념과 구성을 간단히 알아보았습니다...! 끝...!
Kubernetes 클러스터의 control plane을 설정하고 초기화하는 kubeadm init 명령어를 사용하여 마스터 노드를 설정합니다.
kubeadm init 명령어 이후 클러스터 설정 진행에 대한 로그를 확인하실 수 있습니다.
# kubeadm init
[init] Using Kubernetes version: v1.31.1
===== 생략 =====
Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Alternatively, if you are the root user, you can run:
export KUBECONFIG=/etc/kubernetes/admin.conf
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 10.0.0.13:6443 --token 80hzos.m4ql4kdlrv7bpd24 \
--discovery-token-ca-cert-hash sha256:2827b77380f60a82a86f6051c599289f9432f71b7c369216f62da768822d7e02
kubectl 명령어를 사용할 수 있도록 설정 파일을 준비하고 권한 설정을 위해 아래 명령어를 추가로 입력합니다.
Kubernetes 클러스터에서 현재 구성된 모든 노드(node)에 대한 정보를 확인할 수 있습니다.
# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-cn-001 Ready control-plane 5m53s v1.31.1
노드 이름, 상태, 역할, 생성된 시간, 버전 등의 정보를 확인할 수 있습니다.
Kubernetes 클러스터의 핵심 구성 요소들이 실행되는 kube-system 네임스페이스의 리소스를 확인할 수 있습니다.
# kubectl get all -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system pod/coredns-7c65d6cfc9-5gtzj 1/1 Running 0 12m
kube-system pod/coredns-7c65d6cfc9-85swv 1/1 Running 0 12m
kube-system pod/etcd-k8s-cn-003 1/1 Running 0 12m
kube-system pod/kube-apiserver-k8s-cn-003 1/1 Running 0 12m
kube-system pod/kube-controller-manager-k8s-cn-003 1/1 Running 0 12m
kube-system pod/kube-proxy-6gx92 1/1 Running 0 12m
kube-system pod/kube-scheduler-k8s-cn-003 1/1 Running 0 12m
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 12m
kube-system service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 12m
NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
kube-system daemonset.apps/kube-proxy 1 1 1 1 1 kubernetes.io/os=linux 12m
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
kube-system deployment.apps/coredns 2/2 2 2 12m
NAMESPACE NAME DESIRED CURRENT READY AGE
kube-system replicaset.apps/coredns-7c65d6cfc9 2 2 2 12m
Rocky Linux 9.4에서 Kubernetes 클러스터를 구축하는 방법을 알아봤습니다.
먼저, 클러스터 구성을 위해 컨테이너 런타임(CRI-O)을 설치하고, kubeadm, kubelet, kubectl 패키지를 설치한 후, IPv4 포워딩을 활성화해야 합니다.
그 후, kubeadm init 명령어를 사용하여 Kubernetes 클러스터의 control plane을 초기화합니다. 초기화가 완료되면, 클러스터에서 kubectl 명령어를 사용하기 위해 설정 파일을 준비하고 권한을 추가합니다. 그리고 kubelet을 재시작하여 클러스터가 정상적으로 동작하도록 합니다.
마지막으로, kubectl get nodes 명령어로 클러스터의 노드를 확인하고, kubectl get all -A 명령어로 kube-system 네임스페이스에서 Kubernetes의 핵심 구성 요소들이 제대로 실행되고 있는지 확인할 수 있습니다.
지금까지 Kubernetes 클러스터를 구축하는 방법을 간단히 알아보는 시간을 가졌습니다....! 끝...!
Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.
Kubernetes를 사용하기 위해 kubeadm, kubelet, kubectl 패키지 등을 사용하여 클러스터를 구성하거나 Pod를 사용할 수 있습니다.
각 패키지에 대한 내용을 확인해보고 설치하는 방법을 알아보도록 하겠습니다.
패키지별 용도
kubeadm
kubeadm은 Kubernetes 클러스터를 설치하고 관리하는 데 필요한 기본 도구로, 클러스터의 부트스트랩 작업을 자동화하는 역할을 합니다. 또한 kubeadm은 클러스터 초기화, 노드 추가 및 업그레이드와 같은 작업을 쉽게 할 수 있도록 명령어를 제공합니다. 주로 마스터 노드(컨트롤 플레인)를 설정하고 클러스터를 시작하는 데 사용됩니다.
주요 기능
클러스터 초기화 (init)
kubeadm init 명령어를 사용하여 컨트롤 플레인을 초기화하고, 클러스터의 기본 구성 요소들을 설치합니다.
인증서, 키, 구성 파일 등을 생성하고, 필수적인 컨트롤러 컴포넌트들을 설정할 수 있습니다.
노드 추가 (join)
kubeadm join 명령어를 사용하여 워커 노드를 기존 클러스터에 추가합니다.
이를 통해 워커 노드가 마스터 노드에 연결되어 작업을 처리할 수 있습니다.
클러스터 업그레이드
Kubernetes의 새로운 버전이 릴리스될 때, kubeadm upgrade 명령어를 사용하여 클러스터를 업그레이드할 수 있습니다.
kubelet
kubelet은 Kubernetes 클러스터에서 각 노드에 상주하며 Pod와 컨테이너를 관리하는 에이전트입니다. 또한 kubelet은 마스터 노드의 API 서버에서 내려오는 명령을 받아서 해당 노드에서 컨테이너가 올바르게 실행되는지 지속적으로 모니터링하고 관리하는 역할을 합니다. Kubernetes의 기본 구성 요소 중 하나로, Pod의 상태를 보고하고 필요한 경우 컨테이너를 다시 시작하는 등 작업을 수행합니다.
주요 기능
Pod 및 컨테이너 관리
kubelet은 Pod의 정의를 받아 해당 Pod를 생성하고, 올바르게 실행되고 있는지 확인합니다.
컨테이너의 상태를 주기적으로 확인하며, 상태가 이상할 경우 컨테이너를 재시작하여 상태를 유지하도록 합니다.
노드 상태 보고
kubelet은 마스터 노드의 API 서버에 노드의 상태와 자원 사용량(CPU, 메모리 등)을 주기적으로 보고합니다.
이를 통해 클러스터 관리자가 노드의 상태를 모니터링할 수 있습니다.
로깅 및 진단
kubelet은 로그 파일을 관리하고, 시스템의 진단 정보를 수집하여 클러스터의 상태를 확인하는 데 도움을 줍니다.
kubectl
kubectl은 Kubernetes 클러스터와 상호작용하기 위한 명령줄 도구로, 클러스터 내 리소스 관리, 배포, 디버깅 등을 수행할 수 있는 가장 중요한 도구 중 하나입니다. kubectl을 사용하면 Kubernetes API 서버와 통신하여 클러스터 상태를 조회하거나 관리할 수 있으며, Kubernetes 리소스를 생성, 조회, 수정, 삭제하는 다양한 작업을 수행할 수 있습니다.
주요 기능
Kubernetes 리소스 관리
클러스터 내에서 Pod, Service, Deployment, ConfigMap 등과 같은 리소스를 생성, 조회, 업데이트, 삭제할 수 있습니다.
클러스터 상태 모니터링
노드, 네임스페이스, 컨테이너 등의 상태를 확인하고, 로그를 조회하여 애플리케이션 상태를 진단할 수 있습니다.
배포 관리
애플리케이션 배포, 확장, 롤백 등의 작업을 쉽게 수행할 수 있습니다.
설치
kubeadm, kubelet, kubectl 패키지 설치 작업은 Rocky Linux 9.4 버전에서 테스트를 진행했습니다. 또한 각 패키지의 버전은 1.31 버전을 설치하도록 설정하였습니다.
Kubernetes는 Github으로 프로젝트가 관리되고 있습니다. Kubernetes의 최신 릴리즈 노트 를 확인해보면 24년 9월 둘째 주에 릴리즈한 v1.31.1 버전이 최신 버전입니다.
각각의 kubeadm, kubelet, kubectl 패키지 들은 kubernetes GitHub 프로젝트의 리포지토리를 통해 확인할 수 있습니다.
yum install 명령어를 사용하여 kubeadm, kubelet, kubectl 패키지를 설치합니다.
# yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
Last metadata expiration check: 0:00:12 ago on Fri 20 Sep 2024 01:36:55 PM KST.
Package kubelet-1.31.0-150500.1.1.x86_64 is already installed.
Package kubeadm-1.31.0-150500.1.1.x86_64 is already installed.
Package kubectl-1.31.0-150500.1.1.x86_64 is already installed.
Dependencies resolved.
================================================================================
Package Architecture Version Repository Size
================================================================================
Upgrading:
kubeadm x86_64 1.31.1-150500.1.1 kubernetes 11 M
kubectl x86_64 1.31.1-150500.1.1 kubernetes 11 M
kubelet x86_64 1.31.1-150500.1.1 kubernetes 15 M
Transaction Summary
================================================================================
Upgrade 3 Packages
##### 생략 #####
Upgraded:
kubeadm-1.31.1-150500.1.1.x86_64 kubectl-1.31.1-150500.1.1.x86_64
kubelet-1.31.1-150500.1.1.x86_64
Complete!
kubelet은 데몬 형태로 실행되므로 systemctl 명령어를 사용하여 시스템 부팅 시 자동으로 시작되도록 등록하고, 시작합니다.
# systemctl enable --now kubelet
*** 2024-10-17 추가
Kubernetes는 노드의 메모리 관리 방식을 중요하게 여기며, 스왑(Swap)이 활성화된 상태에서는 메모리 관련 문제가 발생할 수 있기 때문에 이를 비활성화해야 합니다.
스왑(Swap) 비활성화 후 kubelet을 재시작 합니다.
# swapoff -a
# sed -i '/ swap / s/^/#/' /etc/fstab
# systemctl restart kubelet
*** 2024-10-30 추가
Linux에서 기본적으로 구동 중인 firewalld 서비스를 종료합니다. API 서버 연결 및 노드 추가 등의 작업 시 방화벽으로 작업이 비정상적으로 동작할 수 있습니다. 해당 서비스를 종료할 수 없다면 허용이 필요한 모든 방화벽 정책 확인 후 방화벽 정책을 추가하여 사용 가능합니다.
kubectl version 명령어를 사용하여 kubectl 패키지가 정상적으로 설치되었는지 확인합니다. 클러스트가 구성되어 있지 않기 때문에 API와 통신할 수 없어 API 서버 연결 오류가 발생할 것입니다.
# kubectl version
Client Version: v1.31.1
Kustomize Version: v5.4.2
The connection to the server localhost:8080 was refused - did you specify the right host or port?
Rocky Linux 9.4에서 kubeadm, kubelet, kubectl 패키지를 설치하는 방법을 알아봤습니다.
먼저, Kubernetes 관련 repo를 등록하고 yum install명령어를 사용하여 각 패키지를 설치합니다. 그 후, 각 패키지별 version 명령어를 사용하여 버전 정보를 확인할 수 있으며, kubelet 및 kubectl 에서는 클러스트가 구성되어 있지 않기 때문에 오류가 발생하는 것을 확인하실 수 있습니다.
지금까지 kubeadm, kubelet, kubectl 패키지를 설치하는 방법을 간단히 알아보는 시간을 가졌습니다....! 끝...!
[kubernetes] kubeadm init "found multiple CRI endpoints on the host" 오류
오류 내용
kubeadm init 명령을 실행할 때 발생하는 "found multiple CRI endpoints on the host" 오류는 시스템에 여러 개의 CRI(Container Runtime Interface) 엔드포인트가 존재할 때 발생하는 문제입니다.
Kubernetes에서 지원하는 컨테이너 런타임은 dockershim, containerd, CRI-O 등이 있으며, 여러 개의 컨테이너 런타임이 설정된 경우 Kubelet이 어떤 컨테이너 런타임을 사용할지 혼란스러워하는 상황이 발생합니다.
# kubeadm init
found multiple CRI endpoints on the host. Please define which one do you wish to use by setting the 'criSocket' field in the kubeadm configuration file: unix:///var/run/containerd/containerd.sock, unix:///var/run/crio/crio.sock
To see the stack trace of this error execute with --v=5 or higher
해결 방법
1. 컨테이너 런타임 소켓을 확인합니다.
/var/run/dockershim.sock
/var/run/containerd/containerd.sock
/var/run/crio/crio.sock
2.1 kubeadm init 명령에 --cri-socket 옵션을 사용하여 특정 CRI 소켓을 지정합니다
Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.
runc는 Kubernetes와 같은 컨테이너 오케스트레이션 시스템에서 컨테이너 런타임으로 사용되며, 컨테이너를 실제로 실행하는 핵심적인 역할을 담당합니다. Kubernetes에서는 runc가 containerd와 같은 상위 컨테이너 런타임과 함께 동작하며, 컨테이너의 생성, 실행, 종료 등의 작업을 수행합니다.
Kubernetes를 사용하기 전 runc를 설치하고 확인하는 것을 테스트 해보도록 하겠습니다.
설치
runc 설치 작업은 Rocky Linux 9.4 버전에서 테스트를 진행했습니다.
runc는 github으로 프로젝트가 관리되고 있습니다. runc의 최신 릴리즈 노트 를 확인해보면 24년 9월 첫째주에 릴리즈한 v1.1.14 버전이 최신 버전입니다. 최신 버전인 v1.1.14버전을 설치해보겠습니다.
wget 명령어를 사용하여 runc 바이너리 파일을 다운로드 받습니다. 버전 및 CPU 아키텍처에 맞는 바이너리 파일을 지정합니다.
먼저, GitHub에서 최신 버전의 runc 바이너리 파일을 다운로드하고, /usr/local/sbin 경로에 업로드 후 권한을 할당합니다. 그 후, runc --version 명령어를 통해 runc 버전 정보 및 실행을 확인할 수 있으며, 추가적으로 runc 명령어를 통해 직접적으로 컨테이너를 실행하거나 관리할 수 있습니다.
지금까지 runc를 설치 및 확인 방법을 간단히 알아보는 시간을 가졌습니다....! 끝...!
Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.
Kubernetes에서의 CRI-O(Container Runtime Interface - Open Container Initiative)는 컨테이너 런타임으로서, Kubernetes의 kubelet과 통신하여 컨테이너의 생성, 실행, 관리 등을 수행합니다. CRI(Container Runtime Interface)를 통해 Kubernetes의 명령을 수신하고, 컨테이너 이미지를 풀링하거나 컨테이너를 시작, 정지, 삭제하는 작업을 수행합니다.
Kubernetes 를 사용하기 전 CRI-O를 설치하고 확인하는 것을 테스트 해보도록 하겠습니다.
설치
CRI-O 설치 작업은 Rocky Linux 9.4 버전에서 테스트를 진행했습니다.
CRI-O는 github으로 프로젝트가 관리되고 있습니다. CRI-O의 최신 릴리즈 노트를 확인해보면 24년 9월 6일을 기준으로 3일 전에 릴리즈한 v1.30.5 버전이 최신 버전입니다. 최신 버전인 v1.30.5버전을 설치해보겠습니다.
CRI-O를 yum 명령어를 통해 설치하기 repo를 등록해줍니다. repo에는 최신 버전인 CRI-O를 설치하기 위해 v1.30 버전 값을 입력하였습니다.
위 명령어까지 모두 정상적으로 확인되었다면 CRI-O 설치는 정상적임을 확인하실 수 있습니다.
Rocky Linux 9.4 및 기타 OS에서 CRI-O를 설치하여 kubernetes에서 컨테이너 런타임으로 사용할 수 있습니다.
먼저, yum을 사용해 CRI-O 설치를 위해 필요한 repository를 설정하고 최신 버전인 v1.30.5를 설치합니다. 설치 후 systemctl 명령어로 CRI-O 서비스를 시작하고 자동으로 재시작되도록 설정합니다. 설치가 완료된 후, systemctl status crio 명령어로 서비스 상태를 확인하고, crio --version 명령어로 CRI-O 버전을 확인합니다.
마지막으로 /var/run/crio/crio.sock 경로에 소켓이 정상적으로 생성되었는지 확인하여 Kubernetes와 연동할 수 있는지 점검할 수 있습니다.
지금까지 CRI-O 설치 및 설치 방법을 간단히 알아보는 시간을 가졌습니다....! 끝...!
Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.
Kubernetes에서의 containerd는 컨테이너를 실행하고 관리하는 역할을 하는 컨테이너 런타임으로, 컨테이너의 라이프사이클(생성, 실행, 종료)을 처리합니다. Kubernetes는 CRI(Container Runtime Interface)를 통해 containerd와 통신하여 파드 내 컨테이너를 조정하고 상태를 모니터링합니다.
Kubernetes 를 사용하기 전 containerd를 설치하고 확인하는 것을 테스트 해보도록 하겠습니다.
설치
containerd 설치 작업은 Rocky Linux 9.4 버전에서 테스트를 진행했습니다.
containerd는 github으로 프로젝트가 관리되고 있습니다. containerd의 최신 릴리즈 노트를 확인 후 설치하고자 하는 버전 및 OS에 맞는 패키지를 wget 명령어로 다운로드 받습니다.
Kubernetes 노드가 systemd 기반으로 관리되지만 containerd가 cgroupfs를 사용하면, 두 가지 cgroup 관리자가 충돌할 수 있습니다. 이로 인해 성능 저하, 리소스 관리 실패, 컨테이너의 불안정한 상태 등이 발생할 수 있으므로 systemd 기반의 cgroup 드라이버를 사용하도록 설정을 변경합니다.
우선 runc를 사용하여 systemd 기반의 cgroup-을 사용할 수 있도록 runc를 설치합니다.
Rocky Linux 9.4 및 기타 OS에서 containerd를 설치하여 kubernetes에서 컨테이너 런타임으로 사용할 수 있습니다.
먼저, GitHub에서 최신 버전의 containerd 패키지를 다운로드하고, /usr/local 경로에 압축을 풀어 설치를 진행합니다. 그 후, containerd.service 파일을 /usr/local/lib/systemd/system/ 경로에 추가하고, systemctl을 사용해 데몬 리로드 후 containerd를 활성화합니다. 설치 후, systemctl status 및 containerd --version 명령어를 통해 containerd가 정상적으로 구동 중인지 확인할 수 있습니다.
지금까지 containerd 설치 및 설치 방법을 간단히 알아보는 시간을 가졌습니다....! 끝...!
