쿠버네티스(kubernetes) (1) - 기본 이론 및 설치 구성

Share

Last Updated on 4월 17, 2024 by Jade(정현호)

Container Orchestration

리눅스 컨테이너라는 기술은 소프트웨어 서비스를 실행하는 데 필요한 특정 버전의 프로그래밍 언어 런타임 및 라이브러리와 같은 종속 항목과 애플리케이션 코드를 함께 포함하는 경량 패키지입니다.

컨테이너는 운영체제 수준에서 CPU, 메모리, 스토리지, 네트워크 리소스를 쉽게 공유할 수 있게 해주며 컨테이너가 실제로 실행되는 환경에서 애플리케이션을 추상화 할 수 있는 논리 패키징 메커니즘을 제공합니다.

이런 컨테이너에는 LXC 그리고 가장 유명한 도커(Docker)가 있으며 그 외  containerd, CRI-O 등이 존재합니다.

다수의 컨테이너를 등장하는 환경 그리고 다수의 서버를 사용하는 환경에서는 도커를 관리하기 위한 다른 솔루션 또는 툴이 필요 하였고 이런 컨테이너를 관리하기 위해 나온 툴이 컨테이너 오케스트레이션입니다.

컨테이너 오케스트레이션은 컨테이너의 배포, 관리, 확장, 네트워킹을 중앙관리 하며, 자동화합니다. 수백 또는 수천 개의 리눅스 컨테이너와 호스트를 배포하고 관리해야 하는 기업에서는 컨테이너 오케스트레이션을 활용하여 더욱 컨테이너를 잘 사용할 수 있게 합니다.

컨테이너 오케스트레이션은 컨테이너를 사용하는 어떤 환경에서든 사용할 수 있습니다. 또한 재설계할 필요 없이 각기 다른 환경 전반에 동일한 애플리케이션을 배포하는 데에도 도움이 됩니다. 컨테이너에 마이크로서비스를 구현하면 스토리지, 네트워킹, 보안과 같은 서비스를 간편하게 오케스트레이션 할 수 있습니다

이런 컨테이너 오케스트레이션에는 아주 다양한 여러 형태가 존재합니다.

[docker.com/blog(L)]

먼저 Docker swarm 은 별도로 개발이 되다가 도커 1.12 버전부터 스웜 모드(Swarm mode) 라는 이름으로 합쳐졌습니다 도커 스웜은 도커 컨테이너를 위한 클러스터링, 스케줄링 툴로 스웜을 이용하면 여러 개의 서버와 컨테이너 관리를 쉽게 할 수 있으며 도커의 모든 명령어와 compose 등을 그대로 사용할 수 있는 툴입니다.


그외 컨테이너 오케스트레이션에는 대표적인 쿠버네티스가 있으며, Rancher(Suse), Apache Mesos, Nomad by HashiCorp, Red Hat Openshift, Tanzu by VMware 등이 있습니다.

[subicura.com/container-orchestration(L)]


또한 각 클라우드 서비스에서는 컨테이너 오케스트레이션을 클라우드 서비스로도 제공하고 있으며 클
라우드에서 PaaS 형태의 서비스에서 대표적인 서비스 상품 이기도 합니다.

쿠버네티스를 기반으로 하여 각 클라우드 마다 관리 편의성 등의 기능을 추가하여 각자의 장/단점을 가지고 있으며 대표적인 클라우드의 완전 관리형 쿠버네티스 서비스는 아래와 같이 있습니다


Amazon’s Elastic Kubernetes Service (EKS)
Microsoft’s Azure Kubernetes Service (AKS)
Google’s Kubernetes Engine (GKE)
Oracle's Container Engine for Kubernetes(OKE)
Alibaba Cloud Container Service for Kubernetes (ACK)

이외 더 많은 클라우드 회사의 관리형 쿠버네티스 서비스는 다양하게 존재합니다.
          

쿠버네티스란 무엇인가요?

쿠버네티스는 구글(Google)이 만들었고, 구글은 예전부터 컨테이너를 아주 많이 사용을 하였고, 지금도 아주 많이 사용을 하고 있는 회사 중에 하나입니다.

일례로 대표적인 서비스인 유튜브에서도 아주 많은 컨테이너를 사용을 하는 것으로 알려져 있습니다

이러한 컨테이너를 구글은 일주일에 수십억개의 컨테이너를 생성, 배포를 하고 있었으며 많은 수의 컨테이너와 컨테이너가 동작하는 서버들을 관리하기 위한 솔루션 또는 툴이 필요 하였고 그런 관리 및 배포시스템인 컨테이너 오케스트레이션을 만든 것이 쿠버네티스 입니다.

오픈소스화 하여 지금은 CLOUD NATIVE COMPUTING FOUNDATION(CNCF) 에서 소스가 이관되어 관리 등이 되고 있습니다.

쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래되었으며 K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기입니다.

구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화 하였으며, 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 15년 이상의 구글 경험과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다고 표현하고 있습니다.


컨테이너 오케스트레이션에는 Docker swarm 을 포함하여 여러 오케스트레이션이 있으나 쿠버네티스 발표 이후 현재는 사실상 쿠버네티스가 표준 형태로 통용되고 있습니다.

쿠버네티스의 성장 속도 와 인기가 매우 높으며 사용률 등이 높고 위에서 언급한 메이저 클라우드사에서도 쿠버네티스가 관리형 서비스로 제공되고 있습니다.



그래서 컨테이너 오케스트레이션의 사실상의 표준이 되는 것이 쿠버네티스 이며, 쿠버네티스를 기반으로하여 추가 기능이나 관리 편의성 등을 더한 제품도 많이 있으며 그 만큼 컨테이너 오케스트레이션의 표준격으로 자리 잡았음을 의미합니다.

쿠버네티스는 기능 및 특작정으로 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이라고 하며 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다고 합니다. 그리고 무엇보다 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있고, 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다고 설명되고 있습니다.
          

Containerd

쿠버네티스를 구성 하기전에 컨테이너 런타임에 대해서 간략하게 설명을 후에 OS 설정 및 containerd 를 설치하도록 하겠습니다.
            

컨테이너 런타임

쿠버네티스 에서 사용할 수 있는 CONTAINER RUNTIME컨테이너 런타임 인터페이스(CRI) 요구사항을 만족하는 런타임을 사용해야 하며 대표적으로 사용되는 컨테이너로 런타임으로는 containerdCRI-O , docker 가 있습니다.

쿠버네티스 버전 1.20 에서 도커(docker) 지원에 대해서 Deprecated 되었으며, 1.24 버전에서는 Dockershim 이 제거(Removal) 되었습니다.

관련 내용)


containerd 는 Docker가 CNCF(Cloud Native Computing Foundation) 에 기증 한 컨테이너 런타임입니다. 현재 Docker 엔진의 컨테이너 런타임으로도 사용하고 있습니다.

Docker Engine 이라는 하나의 패키지에 API, CLI, 네트워크, 스토리지 등 여러 기능들을 모두 담겨 있는 구성에서, Docker에 의존하고 있던 Kubernetes에서는 Docker 버전이 새로 나올 때마다 Kubernetes가 크게 영향을 받는 일들이 계속 생기게 되었습니다.

그래서 OCI 라는 프로젝트를 시작하여 컨테이너에 관한 표준을 정하는 일들을 시작하게 되었고, Docker 에서는 OCI 표준을 준수하는 containerd 라는 Container Runtime 을 만들게 되었습니다.

Kubernetes에서는 OCI 표준을 준수하는 이미지들을 실행할 수 있는 Container Runtime Interface, 이하 CRI 스펙을 버전 1.5부터 제공함으로써 Docker 버전과 무관하게 OCI 표준을 준수하기만 하면 어떤 컨테이너 이미지도 Kubernetes 에서 실행 가능한 환경이 만들어지게 되었습니다.


추가로 Red Hat, Intel, SUSE, Hyper, IBM 쪽에서도 OCI 표준에 따라 Kubernetes 전용 Container Runtime 을 만들었는데 이것이 CRI-O 입니다.


containerdCRI-O 이 두가지 Container Runtime 이 현재 가장 널리 사용되고 있으며 containerd 는 Docker Engine에 기본으로 탑재되어 있어서 사실상 최근의 Docker 버전을 사용하는 것은 내부적으로 사용되는 Container Runtime 은 containerd 를 사용하게 되는 것이 됩니다.

또한 docker build 커맨드를 통해 생성되는 이미지도 역시 OCI Image Spec 을 준수하기 때문 별도의 작업 없이 containerd 로 실행할 수 있습니다.


그에 따라서 포스팅에서도 내용이 갱신(수정)된 부분이 있으며 여기 포스팅 글에서는 containerd 으로 설치를 진행하도록 하겠습니다

설치는 root 유저로 진행하도록 하겠으며, 설치 이후 일반 유저를 사용하도록 하겠으며, 일반 유저는 devops 라는 유저를 사용하도록 하겠습니다.
                  

설치 환경 개요

쿠버네티스 클러스터를 구성하는 Machine(머신)들은 노드(node) 라고 하며, 쿠버네티스 클러스터 내 노드들은 물리 머신 이거나 가상 머신 일 수 있습니다.

노드에는 두가지 종류 가 있습니다.

클러스터의 두뇌 역할을 하는 마스터 노드(Master-node) 가 있으며 클러스터, 워커 노드 ,pod 관리 및 배포 등의 주요 일을 하는 노드입니다.

파드(pod)들을 통해 실제 컨테이너 이미지들이 동작되는 워커 노드(Worker-node) 입니다.


포스팅에서 다음과 같은 구성으로 진행하였습니다.

• 노드 : 마스터 노드 1대   / 워커 노드 2대
• Spec : vCPU 2 , RAM 4G
• OS   : CentOS 7.9
• hosts : master(192.168.56.55) , worker1(56) , worker2(57)
    (괄호 안에는 IP 주소 와 주소 끝자리를 의미)
• 쿠버네티스 버전 : 1.24.2
• containerd: 1.6.6

쿠버네티스 클러스터에서 3대의 노드를 사용하였으며 마스터 노드 1대, 워커노드 2대 로 구성하였습니다.


kubeadm 사용하기 위한 최소 사양은 2CPU(vCPU), 2GB RAM입니다. 2CPU가 안된다면 kubeadm init 시 다음과 같은 에러 발생합니다.
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR NumCPU]: the number of available CPUs 1 is less than the required 2


마스터 노드 와 워커 노드 모두에서 공통적으로 진행할 내역에 대해서 설치를 진행하도록 하겠습니다.

Note

쿠버네티스는 v1.20 이후 컨테이너 런타임으로서 도커를 사용 중단(deprecating) 되었으며, Kubernetes 1.24 릴리스에서부터 Dockershim 이 제거되었습니다.

그에 따라서 포스팅 내용이 containerd 로 CONTAINER-RUNTIME 을 사용하는 것으로 설치 관련된 일부 내용이 갱신(수정) 되었습니다.

         

기본 패키지 설치 및 구성

containerd 설치 전에 필요한 일부 패키지 등을 설치하도록 하겠습니다.

패키지 설치

-- 기본 필요 패키지 설치
~]# yum install -y bash-completion yum-utils \
rsync git vim net-tools tree bridge-utils


방화벽 비활성화 

그 다음 방화벽 비활성화를 하도록 하겠습니다.

~]# systemctl disable firewalld

~]# systemctl stop firewalld

~]# systemctl status firewalld


containerd 설정 및 커널 파라미터 추가

~]# cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF


~]# cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

## 99-kubernetes-cri.conf 파일 내용 적용
~]# sudo sysctl --system


SELinux 비활성화

~]# vim /etc/selinux/config

#selinux=enforing 
selinux=disabled

* selinux=disabled 로 수정


swap off

쿠버네티스 구성시 OS Swap의 비활성화하는 것이 권장 사항입니다. OS의 swap 를 비활성 하도록 하겠습니다.

먼저 /etc/fstab 을 수정하여 주석 처리합니다.

~]# vim /etc/fstab

# xxxxxx   swap  swap  defaults 0 0 
<-- 주석 처리 합니다


주석 처리를 하였다면 swap 을 비활성화 합니다.

~]# sudo swapoff -a


swap을 off 하였다면 메모리와 swap 현황을 확인합니다.

~]# free -m


만약 swap 이 비활성화가 안된다면 OS를 재부팅을 합니다.

-- 재부팅
~]# sudo reboot

             

Repository 구성 및 설치

Repository 를 구성 및 containerd 를 설치합니다.

containerd 설치

-- Repository 구성
~]$ sudo yum install -y yum-utils
~]$ sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo


-- containerd 설치
~]$ sudo yum install -y containerd.io


containerd 설정

~]# sudo mkdir -p /etc/containerd
~]# containerd config default | sudo tee /etc/containerd/config.toml


systemd cgroup 드라이버의 사용(SystemGroup 설정)

## /etc/containerd/config.toml 파일 수정

sudo vi /etc/containerd/config.toml


[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  ...
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true  <-- false 에서 true 로 변경


containerd 활성화/시작

containerd 활성화 및 시작합니다.

-- 서비스 데몬 reload
~]# systemctl daemon-reload


-- 서비스 활성화 및 실행
~]# systemctl enable containerd

~]# systemctl restart containerd

             

유저 생성 및 그룹 추가

devops 라는 계정을 생성 후 docker 및 쿠버네티스를 컨트롤 할 수 있도록 그룹에 추가하도록 하겠습니다.
그룹에 추가하면 일반 계정인 devops 에서도 docker, 쿠버네티스를 시작, 중지, 삭제 등의 컨트롤이 가능해집니다.

유저/그룹 설정

-- 그룹 생성
~]# groupadd devops


-- 유저생성 생성
~]# useradd -g devops -G docker devops


-- 패스워드 지정
~]# passwd devops
Changing password for user devops.
New password: [패스워드 입력]
Retype new password: [패스워드 입력]
passwd: all authentication tokens updated successfully.


일반 계정에 sudo 권한 추가

-- 일반 계정인 devops 계정에 sudo 권한 추가
~]# echo "devops ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/devops-users

일반 계정에 패스워드 없이 sudo 권한도 추가가 완료되었습니다

그 다음으로 쿠버네티스 설치를 진행하도록 하겠습니다.

         

kubernetes(쿠버네티스) 설치

쿠버네티스 설치를 위해서 마스터 노드와 워커 노드에 Repository 구성, 설치 등을 진행하도록 하겠습니다.

먼저 마스터 노드와 워커 노드에 공통 구성/설치 내역을 진행하도록 하겠습니다.
           

Repository 구성

kubernetes 설치를 위한 Repository 구성하도록 하겠습니다.

~]$ vim /etc/yum.repos.d/kubernetes.repo

[kubernetes]
name=kubernetes repository
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg



~]$ yum repolist

kubernetes/signature                                                                                                                                                                                                        |  844 B  00:00:00     
Retrieving key from https://packages.cloud.google.com/yum/doc/yum-key.gpg
Importing GPG key 0x307EA071:
 Userid     : "Rapture Automatic Signing Key (cloud-rapture-signing-key-2021-03-01-08_01_09.pub)"
 Fingerprint: 7f92 e05b 3109 3bef 5a3c 2d38 feea 9169 307e a071
 From       : https://packages.cloud.google.com/yum/doc/yum-key.gpg
Is this ok [y/N]: y

/etc/yum.repos.d/kubernetes.repo 파일을 생성하여 위의 내용을 입력 후 yum repolist 를 실행을 합니다.

repository 를 구성이 완료되었다면 그 다음으로 패키지, initialize, Add-on, Cluster Join 설치 및 구성하도록 하겠습니다.

kubernetes 패키지 설치

~]$ yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes


여기 까지는 마스터 노드, 워크 노드 공통으로 진행을 하였고 다음 에는 마스터 노드, 워커 노드 를 나눠서 진행하도록 하겠습니다.
        

마스터 노드에서 실행

먼저 쿠버네티스 서비스를 실행을 하도록 하겠습니다.

~]$ systemctl enable kubelet

~]$ systemctl start kubelet


환경변수 설정

KUBECONFIG 와 bash completion 관련하여 먼저 설정하도록 하겠습니다.

~]# vi ~/.bash_profile


export KUBECONFIG=/etc/kubernetes/admin.conf
source <(kubectl completion bash)
<-- 추가


-- 환경변수 적용
~]# source ~/.bash_profile


kubeadm init 실행

구문은 아래와 같이 실행을 하면 됩니다.
kubeadm init --pod-network-cidr=x.x.x.x/x --apiserver-advertise-address=x.x.x.x

• pod-network-cidr 는 사용하지 않는 대역대 으로 설정합니다. (실제로 우리가 사용할 대역대는 아님)
• apiserver-advertise-address 는 master node 의 ip address 을 입력 합니다.

kubeadm init 를 실행하도록 하겠습니다.

~]# kubeadm init --pod-network-cidr=192.168.200.0/24 --apiserver-advertise-address=192.168.56.55


---------------------------------------------------------------------------------------------------------------------


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 192.168.56.55:6443 --token 7zii5y.46i1zomowgto4kd9 \
        --discovery-token-ca-cert-hash sha256:f3444ffb33a950a5bf36e01269395b82b27b9234b8c6e2a8e0e1c65cdda99c10 

---------------------------------------------------------------------------------------------------------------------

위의 join 구문은 워커 노드에서 실행을 해야 함으로 별도로 기록이나 copy 해야 합니다.

위의 구문이나 token 은 아래 명령어를 통해 다시 확인할 수 있습니다.

~]# kubeadm token list


~]# kubeadm token create --print-join-command


[참고] kubeadm init 실패 시 reset 을 실행합니다.
~]# kubeadm reset
               

kubernetes Addon


쿠버네티스 에는 여러 Addon 이 있습니다.

네트워킹과 네트워크 폴리시
서비스 검색 시각화 & 제어
인프라스트럭처
레거시 애드온

기본적으로 설치가 필요한 network-policy-provider(네트워크 폴리시 제공자) 를 설치하도록 하겠습니다.


설치할 수 있는 Network Policy 는 여러가지가 있으며 아래와 같은 종류가 있습니다.

캘리코(Calico) ,실리움(Cilium) , 큐브 라우터(Kube-router) , 로마나(Romana), 위브넷(Weave Net), Antrea 등이 있습니다.
포스팅에서는 캘리코(Calico) 와 위브넷(Weave Net) 두 가지 설치에 대해서 기술하도록 하겠습니다.

사용하고자 하는 Network Policy를 선택하시면 됩니다.

• Calico

~]# kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml


• 위브넷(Weave Net)

~]# kubectl apply -f https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')



• 파드 확인

~]# kubectl get pods --all-namespaces
~]# kubectl get pods -n kube-system -o wide


여기까지 설정되었다면 아래와 같이 마스터 노드에서 클러스터 노드 정보를 확인할 수 있습니다.

~]# kubectl get node
NAME     STATUS   ROLES                  AGE     VERSION
master   Ready    control-plane,master   3h43m   v1.24.2


추가적으로 -o wide 옵션으로 컨테이너 런타임 정보도 확인해보도록 하겠습니다.

~]# kubectl get nodes -o wide
NAME     STATUS   ROLES           AGE   VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION           CONTAINER-RUNTIME
master   Ready    control-plane   12m   v1.24.2   192.168.56.55   <none>        CentOS Linux 7 (Core)   3.10.0-1160.el7.x86_64   containerd://1.6.6


위의 내용처럼 현재 쿠버네티스가 컨테이너 런타임으로 containerd 를 사용하는 것을 확인할 수 있습니다.
            

워커 노드에서 실행


먼저 kubelet 를 활성화하겠습니다.

~]# systemctl enable kubelet


이제 Cluster Join 을 하도록 하겠습니다. 위에서 마스터 노드에서 init 실행 후 확인된 구문을 통해서 진행하시면 됩니다.

~]# kubeadm join 192.168.56.51:6443 --token 7zii5y.46i1zomowgto4kd9 \
>         --discovery-token-ca-cert-hash sha256:f3444ffb33a950a5bf36e01269395b82b27b9234b8c6e2a8e0e1c65cdda99c10 
[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.


위와 같이 완료가 되었다면 마스터 노드에서 get nodes 로 클러스터 노드 정보를 확인해보도록 하겠습니다

~]# kubectl get nodes
NAME      STATUS   ROLES                  AGE     VERSION
master    Ready    control-plane,master   5h16m   v1.21.2
worker1   Ready    <none>                 13m     v1.21.2

* Kubernetes v1.24 부터 ROLES에서 master 표기가 사라졌습니다.


Join 후 직후 kubectl get nodes 로 조회하였을 때 워커 노드의 Status 가 NotReady 가 나올 수 있으며 시간이 지나서 다시 조회하면 Ready 로 변경됩니다. (시간이 소요될 수 있음)

위의 작업은 워커 노드 별로 반복합니다.

Ready 가 안된다면 문제가 있으므로 해결을 해야 합니다.
         

일반 유저 사용 설정

위에서 만든 일반 유저에서 쿠버네티스를 사용하도록 설정하도록 하겠습니다.

마스터 노드에서 아래와 같이 진행하면 됩니다.

-- 일반 유저로 변경
~]# su - devops


-- 디렉토리 생성 및 conf 파일 복사
~]$ mkdir -p ~/.kube
~]$ sudo cp -i /etc/kubernetes/admin.conf ~/.kube/config
~]$ sudo chown $(id -u):$(id -g) ~/.kube/config

~]$ ls -al ~/.kube/config 
-rw------- 1 devops devops 5637 Aug  8 00:01 /home/hadoop/.kube/config


그리고 bash 의 자동 완성을 현재 쉘에 설정을 합니다(.bash_profile)

~]$ echo "source <(kubectl completion bash)" >> ~/.bash_profile

~]$ source ~/.bash_profile


일반 유저에서 위의 설정이 완료되었다면 kubectl 명령어가 사용되는지 확인해봅니다.

~]# kubectl get nodes
NAME      STATUS   ROLES                  AGE     VERSION
master    Ready    control-plane,master   5h16m   v1.21.2
worker1   Ready    <none>                 13m     v1.21.2
worker2   Ready    <none>                 15m     v1.21.2

* Kubernetes v1.24 부터 ROLES에서 master 표기가 사라졌습니다.



여기까지 해서 컨테이너 및 쿠버네티스 설치를 완료하였습니다. 다음 포스팅에서는 파드 생성 및 관리 등을 확인해보도록 하겠습니다
               

Reference

Reference Link
kubernetes.io/what-is-kubernetes
kubernetes.io/addons
kubernetes.io/weave-network-policy
kubernetes.io/container-runtimes
kubernetes.io/upcoming-changes-in-kubernetes-1-24
당황하지 마세요. 쿠버네티스와 도커

containerd는 무엇이고 왜 중요할까?


관련된 다른 글

             

0
글에 대한 당신의 생각을 기다립니다. 댓글 의견 주세요!x