백업스크립트로 데이터를 백업할때 디스크용량이 꽉 차는것을 방지하기 위해 보통은 스크립트 상단에 오래된 백업 파일 또는 디렉토리를 삭제하도록 합니다.

하지만 오래된 디렉토리를 삭제할 경우 그 안의 내용은 지워지지만 디렉토리 자체는 날짜가 갱신되어 (Access, Modify, Change) 삭제가 되지 않습니다.

이 경우 아래와 같이 조치가 가능합니다.

예) 20 으로 시작되는 날짜 디렉토리 중 30일이 초과된 디렉토리 삭제

1) 기존 방법

명령 : find /backup/20* -ctime +30 -exec rm -rf {} \;

결과 : 날짜가 오래된 디렉토리 내 파일은 삭제되지만 디렉토리는 남게됩니다.

2) 새 방법

디렉토리의 변경되지 않는 Birth 날짜와 현재 날짜를 비교하여 삭제

* 참고

파일 또는 디렉토리의 날짜 확인

# stat 20230102
  File: 20230102
  Size: 30         Blocks: 0          IO Block: 4096   디렉토리
Device: 821h/2081d Inode: 1799764911  Links: 4
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-01-11 12:00:01.478938107 +0900
Modify: 2023-01-02 12:00:02.236334564 +0900
Change: 2023-01-02 12:00:02.236334564 +0900
 Birth: 2023-01-02 00:00:01.354856557 +0900

파일 리스트 등의 결과를 변수에 넣고 rsync 로 한줄씩 사용하고자 할때 아래와 같은 현상이 발생되었습니다.

이밖에 다른 경우에도 같은 현상이 나타날 수 있는데, 이때 해결방법은 아래와 같습니다.

방법1)

리스트가 list.txt 에 있는 경우 개행문자를 제거하고

list_new.txt 라는 새로운 파일에 입력합니다.

# tr -d '\r' < list.txt > list_new.txt

방법2)

sed -i 's/^M//' list.txt

여기에서 ^M 은 ctrl 키를 누른 상태에서 v, m 을 순서대로 누르는 것입니다.

(ctrl + v + m)

ssh 접속시 특정 client 에서만 아래와 같이 일치하는 호스트 키를 찾을 수 없다는 메세지가 출력되는 경우가 있습니다.

# ssh sysdocu@192.168.10.2
Unable to negotiate with 192.168.10.2 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

아래와 같이 옵션을 추가하여 접근하면 잘 됩니다.

# ssh -oHostKeyAlgorithms=+ssh-dss sysdocu@192.168.10.2

접속할 일이 빈번할 경우 설정파일을 이용하여 미리 셋팅해 놓으면 해당 옵션 사용 없이 접근이 가능합니다.

# vi ~/.ssh/config

# ssh sysdocu@192.168.10.2

패키지 버전 업데이트 등의 문제로 TLS 버전이 맞지않아 통신이 이루어지지 않는 경우인데,

아래 설정파일을 수정하여 무시하도록 할 수 있습니다.

# vi /etc/mail/access

설정을 적용하고 데몬을 재시작하면 발송이 잘 됩니다.

# makemap hash /etc/mail/access.db < /etc/mail/access

# systemctl restart sendmail

아래 설정 파일을 열고 내용을 수정합니다.

# /etc/mail/sendmail.cf

아래 설정 파일을 열고 내용을 추가 합니다.

# vi local-host-names

데몬을 재시작 해주면 적용이 되고 메일 발송이 잘 이루어집니다.

# systemctl restart sendmail

예)

# wget -qO- https://sysdocu.tistory.com

4. Kubernetes 대시보드 설치

1) 대시보드 설치 및 접근 허용 설정

Kubernetes 는 구성 현황 및 오브젝트들을 GUI 환경에서 볼 수 있도록 지원을 해줍니다.

(control 노드에서)

# kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml

대시보드 접근을 활성화 합니다.

아래 명령이후 쉘로 빠져나오지 않는데, ctrl + z 후 bg (백그라운드 명령) 로 돌려놓고 netstat 로 살펴보면

127.0.0.1 로만 접근이 허용되어 있는것이 보입니다.

# kubectl proxy

이제 다시 fg (포어그라운드 명령) 도 돌리고, ctrl + c 버튼으로 명령을 취소합니다.

어디에서든 접속이 가능하도록 하기 위해 아래 작업을 계속 진행합니다.

kubernetes-dashboard 네임스페이스의 서비스를 확인합니다.

# kubectl get services -n kubernetes-dashboard
NAME                        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
dashboard-metrics-scraper   ClusterIP   10.102.90.181   <none>        8000/TCP   5m14s
kubernetes-dashboard        ClusterIP   10.105.198.81   <none>        443/TCP    5m14s

# kubectl edit services kubernetes-dashboard -n kubernetes-dashboard

접근 가능한 클러스터 IP 가 변경되었습니다.

# kubectl get services -n kubernetes-dashboard
NAME                        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
dashboard-metrics-scraper   ClusterIP   10.102.90.181   <none>        8000/TCP        17m
kubernetes-dashboard        NodePort    10.105.198.81   <none>        443:32085/TCP   17m

웹브라우저에서 컨트롤 노드의 IP 와 포트를 이용해 접근하는데, 꼭 https 프로토콜로 접근합니다.

https://<컨트롤노드IP>:32085

브라우저에 따라 '안전하지 않은 페이지' 로 표시될 수 있는데, 이는 인증서가 아직 없어서 그런 것이므로 그냥 접속하도록 합니다.

토큰 또는 Kubeconfig 둘중 하나의 로그인 방법을 선택해야 하는데, 여기서는 토큰으로 로그인 하는 방법으로 진행하겠습니다.

컨트롤 노드에서 토큰을 생성하기 위해 yaml 파일을 작성합니다.

2) 계정 생성 및 admin 권한 부여

계정을 생성하기 위해 yaml 파일을 아래 내용으로 만듭니다.

# vi dashboard-account.yaml

계정을 생성합니다.

# kubectl create -f dashboard-account.yaml

계정 생성을 확인합니다. (sa : serviceaccount)

# kubectl get sa -n kubernetes-dashboard |grep admin
NAME                   SECRETS   AGE
admin                  0         10s

생성된 계정에 권한을 주기 위해 yaml 파일을 아래 내용으로 만듭니다.

# vi dashboard-role.yaml

권한을 적용합니다.

# kubectl create -f dashboard-role.yaml

적용된 권한을 확인합니다.

# kubectl get clusterrolebinding admin
NAME    ROLE                        AGE
admin   ClusterRole/cluster-admin   12m

이제 로그인에 필요한 계정의 token 을 출력합니다.

Kubernetes 1.24 버전 부터는 kubectl get 명령으로 token 이 확인 되지 않아 아래 내용으로 확인해야 합니다.

# kubectl create token admin -n kubernetes-dashboard
eyJhbGciOiJSUzI1NiIsImtpZCI6IktFTlFFRkt6ajZDX2VnV0NZNs93dWZ6TUhBVFBNY1RnUTBBZWVIa0dSeGcifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlem5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNjcyNzf1ODI0LCJpYXQiOjE2NzI3MjIyMeQsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLzxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOierdWJlcm5ldGVzLWRhc2hib2FyZCIsInNlcnZpY2VhY2NvdWe0Ijp7Im5hbWUiOiJhZG1pbiIsInVpZCI6IjAzYTJlZDAwLWI5ZDAtNDY5OC04NWE3LTE3MzU5ZDI5YzllMyJ9fSwibmJmIjowNjcyNzIyMjI0LCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZXJuZXRlcy1kYXNoYm9hcmQ6YWRtaW4ifQ.iN6W5bbpQRYNUoVss-Z6YtP83SaoG9m2Qe6-V41ypaWT6p12QTDhDEtOXAtP7j9o4Mwm-WrlM_rfqR9vw7F-BeWmfyfjZkCcpkE-sOzQ_NtmTL8OMzfnOmuxYhYnOdvzM8j66yTd8-osEqcQ023Tx1t7nQlbALUwu6G6p1kXx9mtMROnqkQRnr6_e89WejwaCsYC7k4WMs5NkA48Wselmrnww-kf5Fl-y3PFjhWjRIC-IU1nlZALBPBMwIKsTBFCt7RmhsrXD0UA7RacZog5U-eSeYJRKKGKzW7PmFXEwIIdFeCTWUYJOk4-Nn_nfyxe3Ismt7q8xbuh6XDCzmFYaQ

출력된 token 전체를 복사하여 웹브라우저의 로그인 화면 token 입력란에 넣고 [로그인] 버튼을 누르면 관리 페이지에 로그인 할 수 있습니다.

3. Namespace 생성, LimitRange 를 이용한 자원 사용량 제한, POD 및 Deployment 생성, 자원 제한 확인

1) Namespace 생성

test-ns 라는 이름의 네임스페이스를 만듭니다.

# kubectl create ns test-ns

생성된 네임스페이스를 확인합니다.

# kubectl get ns
NAME               STATUS   AGE
calico-apiserver   Active   19h
calico-system      Active   19h
default            Active   20h
kube-node-lease    Active   20h
kube-public        Active   20h
kube-system        Active   20h
test-ns            Active   2s
tigera-operator    Active   19h

2) LimitRange 설정

네임스페이스에 LimitRange 설정을 하기 위해 yaml 파일을 생성합니다.

# vi test-limitrange.yaml

test-ns 네임스페이스에 적용 합니다.

# kubectl apply -f test-limitrange.yaml -n test-ns
limitrange/test-limitrange created

모든 네임스페이스에 설정된 LimitRange 목록을 확인 할 수 있습니다.

# kubectl get limitrange -n test-ns  // 네임스페이스 지정하여 보기

# kubectl get limitrange --all-namespaces                       // 네임스페이스 전체 보기
NAMESPACE        NAME              CREATED AT
test-ns                 test-limitrange   2022-12-29T02:08:54Z

자세한 LimitRange 정보를 보고 싶을땐 아래와 같이 실행합니다.

# kubectl get limitrange test-limitrange --output=yaml -n test-ns

3) POD 생성

httpd 이미지를 이용해 POD 를 생성합니다.

기존에 httpd 이미지를 받지 못하였을 경우 crictl 명령을 이용해 다운로드 합니다.

# crictl pull httpd

Image is up to date for docker.io/library/httpd@sha256:753edbf6bf19a74c580c57f7d98e05b6b34073adc929234da6eb193a8029ab91

POD 을 생성하기 위한 환경 파일을 만듭니다.

# vi test-httpd.yaml

test-ns 네임스페이스 POD 를 생성 합니다.  // yaml 파일을 이용해 POD 를 생성하는 방법

# kubectl apply -f test-httpd.yaml -n test-ns

pod/test-httpd created

생성된 POD 정보를 자세히 보고싶을 경우 아래와 같이 실행합니다.

# kubectl get pods test-httpd --output=yaml -n test-ns

* 참고

POD 를 생성 한 뒤 Namespace 에 LimitRange 를 적용할 경우 기존의 POD 에는 LimitRange 가 반영되지 않습니다.

* 참고 : 네임스페이스를 삭제하면 해당 Namespace 와 쿠버네티스 오브젝트들이 삭제되고, 할당되있던 리소스들이 자동으로 해제됩니다.

# kubectl delete ns test-ns
namespace "test-ns" deleted

4) Deployment 생성

한개의 httpd 컨테이너를 더 만들어 봅니다.

원래는 POD 생성후 Deployment 생성이 순서이지만 Deployment 생성시 POD 이 없다면 자동 생성됩니다.

우선 CRI-O 명령을 이용해 이미지를 다운로드 합니다.

httpd 이미지를 이용해 deployment 를 생성 합니다.  // 명령줄에서 POD를 생성, 배포하는 방법

                                                                                // POD 없이 deployment 하면 POD 자동 생성 후 배포가 됩니다.

자원 사용에 제한을 주기 위해 test-ns 라는 네임스페이스 안에 생성합니다.

# kubectl create deployment test-httpd2 --image httpd -n test-ns
deployment.apps/test-httpd2 created

test-ns 네임스페이스 내 POD 현황입니다.

생성된 POD 는 두 개가 보입니다.

# kubectl get pods -n test-ns
NAME                           READY   STATUS    RESTARTS   AGE
test-httpd                       1/1     Running   0          12m
test-httpd2-7c7c8bd5d-x4jl5       1/1    Running   0          3m55s  // 자동 생성이라 이름에 난수값이 들어감

test-ns 네임스페이스 내 배포 현황입니다.

배포된 컨테이너는 한 개라서 test-httpd2 만 보입니다.

# kubectl get deployments -n test-ns
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
test-httpd2        1/1     1            1           45s

5) LimitRange 적용 확인 (부하 테스트)

이제 httpd 컨테이너 쉘에 접근하여 부하를 주면, control 노드에서 확인되는 부하는

위에서 제한한 LimitRange 한도로 제한되는것을 확인 할 수 있습니다.

# kubectl exec -it test-httpd -n test-ns -- bash    // httpd 컨테이너 쉘 접근

# apt -y update

# apt install stress    // 부하 테스트 패키지 설치 후

# cat /proc/cpuinfo |grep processor |wc -l    // 서버의 코어수 확인

# stress -c 2    // CPU 부하 시작

다른 터미널 창을 띄워 control-node 에서 컨테이너별 자원 사용량 체크 툴을 설치합니다.

# git clone https://github.com/kodekloudhub/kubernetes-metrics-server.git
# cd kubernetes-metrics-server
# kubectl create -f .

# kubectl top pod -n test-ns
NAME                           CPU(cores)   MEMORY(bytes)   
test-httpd                     1000m        24Mi    // 1000m 은 1core 를 의미합니다.
test-httpd2-7c7c8bd5d-x4jl5   1m           0Mi             

컨테이너에서 stress 테스트를 중지했을때

# kubectl top pod -n test-ns
NAME                           CPU(cores)   MEMORY(bytes)   
test-httpd                     1m           23Mi            
test-httpd2-7c7c8bd5d-x4jl5   1m           0Mi  

참고로 노드별 자원 사용량도 확인이 가능합니다.

# kubectl top node -n test-ns
NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
control-node   85m          4%     1759Mi          46%       
work-node-1    27m          1%     1200Mi          31%       
work-node-2    39m          1%     1273Mi          33%     

2. CRI-O 와 Kubernetes 를 활용한 httpd 배포

1) httpd 설치

(control 노드에서)

httpd 이미지를 배포합니다.

# kubectl create deployment httpd --image=httpd
deployment.apps/httpd created

배포 명령 이후 진행상태가 이벤트 로그에 기록되므로 아래와 같이 출력해 볼 수 있습니다.

# kubectl get events |grep httpd
70s         Normal   Scheduled           pod/httpd-975f8444c-5xfch     Successfully assigned default/httpd-975f8444c-5xfch to sysdocu-189114
70s         Normal   Pulling             pod/httpd-975f8444c-5xfch     Pulling image "httpd"
58s         Normal   Pulled              pod/httpd-975f8444c-5xfch     Successfully pulled image "httpd" in 11.734922345s (11.734929076s including waiting)
58s         Normal   Created             pod/httpd-975f8444c-5xfch     Created container httpd
58s         Normal   Started             pod/httpd-975f8444c-5xfch     Started container httpd
70s         Normal   SuccessfulCreate    replicaset/httpd-975f8444c    Created pod: httpd-975f8444c-5xfch
70s         Normal   ScalingReplicaSet   deployment/httpd              Scaled up replica set httpd-975f8444c to 1

httpd 배포 정보를 확인합니다.

# kubectl describe deployment httpd

2) yaml 파일 생성 및 배포

httpd 리소스 템플릿 파일을 생성합니다.

# kubectl get deployment httpd -o yaml > httpd.yaml

생성된 httpd.yaml 파일을 열어 포트를 추가합니다.

# vi httpd.yaml

수정된 yml 파일을 기본 httpd 템플릿으로 갱신 (over write) 합니다.

# kubectl replace -f httpd.yaml

deployment.apps/httpd replaced

갱신 시간으로 이미지 업데이트 내역을 확인 할 수 있습니다.

# kubectl get deployment
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
httpd   1/1     1            1           11m

# kubectl expose deployment/httpd
service/httpd exposed

클러스터 httpd 서비스 IP 를 출력합니다.

# kubectl get svc httpd
NAME    TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
httpd   ClusterIP   10.99.72.96   <none>        80/TCP    5m24s

출력된 클러스터 IP 로 httpd 접근 확인이 가능합니다.

# curl 10.99.72.96:80
<html><body><h1>It works!</h1></body></html>

엔드포인트 httpd 서비스 IP 출력합니다.

# kubectl get ep httpd
NAME    ENDPOINTS         AGE
httpd   10.101.0.195:80   5m51s

출력된 엔드포인트 IP 로 httpd 접근 확인이 가능합니다.

# curl 10.101.0.195:80

<html><body><h1>It works!</h1></body></html>

3) httpd 스케일 아웃 (Replica)

httpd 의 replica 를 3으로 조정하면 3개의 POD 가 생성된 것을 확인 할 수 있습니다.

# kubectl scale deployment httpd --replicas=3
deployment.apps/httpd scaled

복제되는 과정에서 시간이 약간 걸리며 watch 명령으로 모니터링을 해보면 아래와 같이 Ready 와 AVAILABLE 값이 3까지 늘어나는 것이 보입니다.

# watch kubectl get deployment httpd
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
httpd   3/3     3            3           15h

엔드포인트도 POD 개수대로 늘어난 것을 확인할 수 있습니다.

# kubectl get ep httpd
NAME    ENDPOINTS                                        AGE
httpd   10.101.0.129:80,10.101.0.195:80,10.101.0.67:80   41m

이제는 POD 를 삭제해도 replica 개수 3 으로 유지 (자동 생성) 됩니다.

클러스터 IP 로 접근을 해보면 3개의 POD 로 분산되어 접근되는 것을 확인할 수 있습니다.

4) 클러스터 외부에서 접근 허용 설정

현재의 POD 정보 입니다.

# kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
httpd-56b65865c4-74zxp   1/1     Running   0          15h
httpd-56b65865c4-b8phd   1/1     Running   0          10m
httpd-56b65865c4-dkjdc   1/1     Running   0          10m

NAME 값을 이용하여 POD 의 환경 설정값을 확인합니다.

# kubectl exec httpd-56b65865c4-74zxp -- printenv |grep KUBERNETES
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443

현재의 서비스 정보 입니다.

# kubectl get svc
NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
httpd        ClusterIP   10.99.72.96   <none>        80/TCP    51m
kubernetes   ClusterIP   10.96.0.1     <none>        443/TCP   18h

외부에서 접근이 가능하도록 svc 값을 삭제하고 LoadBalancer 형태로 다시 생성해 줍니다.

# kubectl delete svc httpd
service "httpd" deleted

# kubectl expose deployment httpd --type=LoadBalancer
service/httpd exposed

다시 svc 정보를 출력해보면 httpd 가 LoadBalancer 형태로 생성되었으며, EXTERNAL-IP 는 없는 상태입니다.

# kubectl get svc
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
httpd        LoadBalancer   10.96.23.114   <pending>     80:31452/TCP   2m29s
kubernetes   ClusterIP      10.96.0.1      <none>        443/TCP        18h

웹브라우저를 통해 새로 생성된 포트로 접근을 해보면 httpd 초기 페이지가 출력되며, 3개의 POD 로 분산 접근이 됩니다.

http://<서버 공인 IP>:31452

[참조] https://blog.psnote.co.kr/184

Kubernetes 는 컨테이너의 생성, 배포, 실행을 하는 등 컨테이너를 관리하는 오픈소스 플랫폼 입니다.

여기에서는 Ubuntu 22.04 버전의 서버 3대로 (master 노드 1대 / worker 노드 2대) Kubernetes 를 구성하는 방법에 대해 설명합니다.

1. CRI-O 설치

CRI-O 공식 홈페이지 : https://cri-o.io

설치에 앞서 사용하고자 하는 호스트네임을 적용 합니다.

# hostnamectl set-hostname master      // master 노드에서

# hostnamectl set-hostname worker1    // worker1 노드에서

# hostnamectl set-hostname worker2    // worker2 노드에서

(모든 노드에서)

# vi /etc/hosts

운영 할 Kubernetes 버전이 1.26인 경우 CRI-O 버전 1.26을 설치해야 합니다.

# OS=xUbuntu_22.04
# VERSION=1.26

# echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
# echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list

# curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/Release.key | apt-key add -
# curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -

# apt -y update

# apt -y upgrade  // 업그레이드 완료 후 최신 커널로 사용하고자 할 경우 reboot 을 진행합니다.

# apt -y install cri-o cri-o-runc cri-tools

CRI-O 를 실행하고 버전을 확인합니다.

# systemctl enable --now crio

# crio --version

crio version 1.26.4
Version:        1.26.4
GitCommit:      unknown
GitCommitDate:  unknown
GitTreeState:   clean
BuildDate:      2023-08-17T06:08:14Z
GoVersion:      go1.19
Compiler:       gc
Platform:       linux/amd64
Linkmode:       dynamic

...

2. Kubernetes 설치

Kubernetes 공식 홈페이지 : https://kubernetes.io

설치 전, 쿠버네티스 (kubelet) 사용을 위해 SWAP 을 반드시 비활성화 시켜줍니다.

# swapoff -a

# cat /etc/fstab

fstab 에서도 swap 파티션이 존재한다면 주석처리하여 비활성화 시킵니다.

1) kubeadm, kubelet 및 kubectl 설치

다음 패키지들을 설치합니다.
- kubeadm : 클러스터를 부트스트랩하는 명령
- kubelet : 클러스터의 모든 노드에서 실행되는 POD와 컨테이너 시작과 같은 작업을 수행하는 컴포넌트
- kubectl : 클러스터와 통신하기 위한 CLI 유틸리티

(모든 노드에서)

# apt -y install apt-transport-https ca-certificates
# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add
# echo "deb https://apt.kubernetes.io/ " >> ~/kubernetes.list
# mv ~/kubernetes.list /etc/apt/sources.list.d
# apt-y update
# VERSION="1.26.0-00"
# apt -y install kubelet=$VERSION kubeadm=$VERSION kubectl=$VERSION kubernetes-cni

쿠버네티스는 버전이 중요하므로 패키지가 자동으로 설치, 업그레이드 또는 제거되지 않도록 고정 시킵니다.

# apt-mark hold kubelet kubeadm kubectl

kubelet set on hold.
kubeadm set on hold.
kubectl set on hold.

2) 쿠버네티스 필수 환경 구성

(모든 노드에서)

쿠버네티스 운영을 위해 필요한 필수 요소들을 설치하고 구성합니다.

필요한 모듈을 로드하고 부팅시에도 자동 적용되도록 합니다.
# modprobe overlay
# modprobe br_netfilter

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

IPv4 를 포워딩하여 iptables 가 브릿지된 트래픽을 보게 합니다.

sysctl 파라미터를 설정하면, 재부팅 후에도 값이 유지됩니다.
# cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

재부팅하지 않고 sysctl 파라미터를 적용합니다.
# sysctl --system

3) cgroup 드라이버 설정
(모든 노드에서)
CRI-O는 기본적으로 systemd 라는 cgroup 드라이버를 사용합니다. 
# cat <<EOF | sudo tee /etc/crio/crio.conf.d/02-cgroup-manager.conf
[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "systemd"
EOF

4) master 서버 초기화 및 노드 연결

(master 노드에서)

서버간 통신할 사설 네트워크 대역을 설정합니다.

쿠버네티스 구성에 필요한 이미지를 다운로드 받아야 하므로 이 단계에서 시간이 약간 소요됩니다.

# kubeadm init --pod-network-cidr=10.101.0.0/24

아래는 쿠버네티스 컨트롤 플레인이 성공적으로 초기화 되었을때 출력하는 메세지 입니다.

위에 나와있는 안내 대로 추가 명령을 실행합니다.

클러스터 사용을 시작하려면 일반 사용자로 다음을 실행해야 합니다.

(master 노드에서)
# mkdir -p $HOME/.kube
# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# sudo chown $(id -u):$(id -g) $HOME/.kube/config

또는 root 사용자인 경우 다음을 실행할 수 있습니다.
# export KUBECONFIG=/etc/kubernetes/admin.conf

앞으로 SSH 접속시마다 자동으로 환경이 로드 되도록 하면 편리합니다.

# echo 'export KUBECONFIG="/etc/kubernetes/admin.conf"' >> ~/.bashrc

master 노드에서 확인 가능한 노드 상태를 출력합니다.

STATUS 에서 NotReady 로 표시되지만, 아래에서 별도 작업을 통해 Ready 로 변경할 예정입니다.

# kubectl get nodes
NAME           STATUS     ROLES           AGE     VERSION
master             NotReady   control-plane   4m57s   v1.26.0

worker 노드에서는 아래와 같이 master 서버에 join (가입) 합니다.

token 과 hash 값은 쿠버네티스 컨트롤 플레인이 초기화 되었을때 출력된 값으로 합니다.

(worker 노드에서)

# kubeadm join 10.101.0.5:6443 --token fayi8m.4qus4e8y3cnon9nc \
--discovery-token-ca-cert-hash sha256:b5693e9d1a3fd79b64e790d5218369ef9449b211c0c30eef88e6376887ad774b

다시 master 노드에서 확인 가능한 노드 상태를 출력하면 가입된 worker 노드 리스트까지 확인이 됩니다.

(master 노드에서)

# kubectl get node
NAME           STATUS     ROLES           AGE    VERSION
master             NotReady   control-plane   8m1s   v1.26.0
worker1           NotReady   <none>          18s    v1.26.0
worker2           NotReady   <none>          16s    v1.26.0

3. Calico 설치하기

Project Calico 는 Kubernetes에 대한 네트워크 정책 엔진입니다.
Calico 네트워크 정책 집행을 통해 네트워크 세분화 및 테넌트 격리를 구현할 수 있습니다.

Calico 공식 홈페이지 : https://www.tigera.io/project-calico

1) Calico 설치하기

(master 노드에서)

Tigera Calico 연산자 및 사용자 지정 리소스 정의를 설치합니다.
# kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.24.5/manifests/tigera-operator.yaml

필요한 커스텀 리소스를 생성하여 Calico를 설치합니다.

배포하는 yaml 파일에서 CIDR 정보를 자신이 사용하는 네트워크 정보로 수정하고 생성합니다.

# wget https://raw.githubusercontent.com/projectcalico/calico/v3.24.5/manifests/custom-resources.yaml

# sed -i 's/192.168.0.0\/16/10.101.0.0\/24/' custom-resources.yaml 

# kubectl create -f custom-resources.yaml

다음 명령을 사용하여 모든 POD가 실행 중인지 확인합니다.

이 부분에서 모든 STATUS 값이 Running 이 되기까지 약간의 시간이 소요됩니다.

# watch kubectl get pods -n calico-system

NAME                                       READY   STATUS    RESTARTS   AGE
calico-kube-controllers-67df98bdc8-kdt6m   1/1     Running   0          83s
calico-node-hp78g                          1/1     Running   0          83s
calico-node-ntfq4                          1/1     Running   0          83s
calico-node-rwm2s                          1/1     Running   0          83s
calico-typha-7f4f4655f7-6psfv              1/1     Running   0          76s
calico-typha-7f4f4655f7-t7ccr              1/1     Running   0          83s

master 노드에서 POD 를 스케쥴링 할 수 있도록 모든 노드의 taint 를 제거 합니다.

우선 taint 상태를 확인하면 아래와 같이 출력되는데,

이 룰을 없애줘야 kubectl get node 명령으로 출력된 NotReady 상태가 Ready 상태로 변경됩니다.

# kubectl describe nodes |grep -i taint
Taints:             node-role.kubernetes.io/control-plane:NoSchedule
Taints:             <none>
Taints:             <none>

룰 뒤에 - 를 붙이면 제거됩니다.

# kubectl taint nodes master node-role.kubernetes.io/control-plane:NoSchedule-

taint 상태를 다시 확인합니다.

# kubectl describe nodes |grep -i taint

Taints:             <none>
Taints:             <none>
Taints:             <none>

이제 모든 노드의 상태가 Ready 로 돌아왔습니다.
# kubectl get nodes
NAME            STATUS   ROLES           AGE   VERSION
master                Ready    control-plane   36m   v1.26.0
worker1              Ready              14m   v1.26.0
worker2              Ready              12m   v1.26.0

* 참고

worker 노드는 사용 설정에 따라 <none> 이 아닐 경우 NoSchedule 이나 NoExecute 가 있을 수 있는데

제거해야하는 상황에 명령어가 수행되지 않는다면 아래와 같이 worker 노드에서 생성되었던 파일 2개 삭제 및 kubelet 데몬 중지 후 다시 join 을 하면 해결됩니다.

(해당 worker 노드에서)

# rm -f /etc/kubernetes/kubelet.conf
# rm -f /etc/kubernetes/pki/ca.crt 
# systemctl stop kubelet

# kubeadm join 10.101.0.5:6443 --token fayi8m.4qus4e8y3cnon9nc \
--discovery-token-ca-cert-hash sha256:b5693e9d1a3fd79b64e790d5218369ef9449b211c0c30eef88e6376887ad774b

6. Docker PHPMyAdmin 설치

1) 설치 및 설정

접속할 MySQL 이 설치되어 있다는 가정하에 진행합니다. (Docker MySQL 설치)

최신버전의 PHPMyAdmin 이미지를 다운로드 받습니다.

# docker pull phpmyadmin:latest

phpmyadmin 컨테이너 환경 설정을 합니다.

# vi docker-compose.yml

phpmyadmin 컨테이너를 가동 합니다.

# docker compose up -d phpmyadmin

2) PHPMyAdmin 페이지 접근 및 설정

웹브라우저로 관리 페이지에 접근합니다.

예) http://sysdocu.tistory.com:8080

입력란은 아래의 데이터로 입력 합니다.

서버 : mysql          // mysql 컨테이너 이름

사용자명 : root       // mysql 계정 이름

암호 : 12345678    // mysql 계정 패스워드

* mysql 컨테이너 입장에서는 로컬 접근이 아닌, 원격 접근 (호스트 서버 또는 다른 컨테이너) 이므로 접근권한이 없다면 추가해줘야 합니다.