컨테이너 인프라 환경 : 리눅스 운영 체제의 커널 하나에서 여러 개의 컨테이너가 격리된 상태로 실행되는 인프라 환경
쿠버네티스는 컨테이너 관리 도구라기 보다는 컨테이너 오케스트레이션을 위한 솔루션
-> 다수의 컨테이너를 유기적으로 연결, 실행, 종료할 뿐만 아니라 상태를 추적하고 보존하는 등 컨테이너를 안정적으로 사용할 수 있게 만들어주는 것
[컨테이너 오케스트레이션 솔루션 비교]
구분 | 도커 스웜 | 메소스 | 노매드 | 쿠버네티스 |
---|---|---|---|---|
설치 난이도 | 쉬움 | 매우 어려움 | 쉬움 | 어려움 |
사용 편의성 | 매우 좋음 | 좋음 | 매우 좋음 | 좋음 |
세부 설정 지원 | 거의 없음 | 있음 | 거의 없음 | 다양하게 있음 |
안정성 | 매우 안정적임 | 안정적임 | 안정적임 | 매우 안정적임 |
확장성 | 어려움 | 매우 잘 됨 | 어려움 | 매우 잘 됨 |
정보량 | 많음 | 적음 | 적음 | 매우 많음 |
에코 파트너 | 없음 | 거의 없음 | 있음 | 매우 많음 |
학습 곡선 | 쉬움 | 매우 어려움 | 어려움 | 어려움 |
-> 이렇게 설치 난이도는 어려워도 그 밖의 요소들에서 많은 장점을 가지고 있기 때문에 쿠버네티스를 사용한다.
이 책에서는 학습을 위해 사용자 설정이 가장 많이 필요한 kubeadm으로 쿠버네티스를 구성함.
또한 쿠버네티스가 설치되는 서버 노드는 가상 머신을 이용해 실제 온프레미스에 가깝게 구성
이 책의 실습 코드는 아래 주소에서 확인할 수 있다.
https://github.com/sysnet4admin/_Book_k8sInfra
슈퍼푸티를 열어 m-k8s를 더블클릭해 터미널에 접속
kubectl get nodes 명령으로 쿠버네티스 클러스터에 마스터 노드와 워커 노드들이 정상적으로 생성되고 연결됐는지 확인
관리자나 개발자가 파드를 배포할 때
사용자가 배포된 파드에 접속할 때
1. kube-proxy : 쿠버네티스 클러스터는 파드가 위치한 노드에 kube-proxy를 통해 파드가 통신할 수 있는 네트워크를 설정함.
2. 파드 : 이미 배포된 파드에 접속하고 필요한 내용을 전달받음. 이때 대부분 사용자는 파드가 어느 워커 노드에 위치하는지 신경쓰지 않아도 됨.
쿠버네티스틑 선언적인 시스템 구조 -> 각 요소가 추구하는 상태를 선언하면 현재 상태와 맞는지 점검하고 그것에 맞추려고 노력하는 구조로 돼 있다는 뜻.
kubectl
1. 슈퍼푸티에서 w3-k8s를 더블클릭해 터미널에 접속
kubelet
m-k8s에서 nginx 웹 서버 파드를 배포
배포된 파드가 정상적으로 배포된 상태인지 확인
파드가 배포된 워커 노드를 확인
-o : 출력을 특정 형식으로 해주는 옵션. wide : 제공되는 출력 형식 중에서 출력 정보를 더 많이 표시해주는 옵션
배포된 노드인 w1-k8s에 접속해 kubelet 서비스를 멈춤
m-k8s에서 상태를 확인하고 파드를 삭제
파드의 상태를 확인
-> 삭제하고 있지만 kubelet이 작동하지 않는 상태라 파드는 삭제되지 않는다.
w1-k8s에서 kubelet을 복구
m-k8s에서 nginx-pod가 삭제됐는지 확인
-> kubelet에 문제가 생기면 파드가 제대로 관리되지 않음을 확인
kube-proxy
kube-proxy에 문제가 생기는 상황을 테스트하기 위해 m-k8s에서 다시 파드를 배포
파드의 IP와 워커 노드를 확인
파드의 IP로 nginx 웹 서버 메인 페이지 내용을 확인
w3-k8s에 접속해 파드가 위치한 워커 노드에서 br_netfilter 모듈을 제거
네트워크를 다시 시작해 변경된 내용을 적용
-> kube-proxy에 문제가 생기는 상황을 만듦
m-k8s에서 파드의 nginx 웹 서버 페이지 정보를 받아옴
파드 상태를 확인
-> 파드의 노드 위치와 IP, 상태 모두 문제 없음. 하지만, kube-proxy가 이용하는 br_netfilter에 문제가 있어서 파드의 nginx 웹 서버와의 통신만이 정상적으로 이루어지지 않는 상태
정상적으로 파드의 nginx 웹 서버 정보를 받아올 수 있는 상태로 만들기 위해 워커 노드에서 br_netfilter를 커널에 적재하고 시스템을 다시 시작해 적용
m-k8s에서 파드 상태를 확인
-> RESTART가 1로 증가돼 파드가 1회 다시 시작했다고 뜨고, IP가 변경된 것을 확인할 수 있음
바뀐 IP로 curl 명령을 실행해 파드로부터 정보를 정상적으로 받아오는지 확인
배포한 파드를 삭제
파드가 잘 생성됐는지 확인
create 방식으로 파드 생성해보기 (deployment를 추가해서 실행해야 함)
생성된 파드 확인
생성된 파드의 IP 확인
각 파드에서 curl 명령을 실행해 웹 페이지 정보를 받아오는지 확인
run으로 파드를 생성하면 단일 파드 1개만 생성되고 관리.
create deployment로 파드를 생성하면 디플로이먼트라는 관리 그룹 내에서 파드가 생성됨.
파드와 디플로이먼트는 스펙과 상태 등의 값을 가지고 있음. 이러한 값을 가지고 있는 파드와 디플로이먼트를 개별 속성을 포함해 부르는 단위가 오브젝트임.
기본 오브젝트
파드 : 쿠버네티스에서 실행되는 최소 단위. 독립적인 공간과 사용 가능한 IP를 가지고 있음. 하나의 파드는 1개 이상의 컨테이너를 갖고 있기 때문에 여러 기능을 묶어 하나의 목적으로 사용할 수 있음. 그러나 대부분 1개의 파드에 1개의 컨테이너를 적용함
네임스페이스 : 쿠버네티스 클러스터에서 사용되는 리소스들을 구분해 관리하는 그룹. 특별히 지정하지 않으면 기본으로 할당되는 default, 쿠버네티스 시스템에서 사용되는 kube-system, 외부에서 쿠버네티스 클러스터 내부로 접속하게 도와주는 컨테이너들이 속해있는 metallb-system 등이 있음
볼륨 : 파드가 생성될 때 파드에서 사용할 수 있는 디렉터리를 제공하지만 파드가 사라지더라도 저장과 보존이 가능한 디렉터리를 볼륨 오브젝트를 통해 생성하고 사용할 수 있음.
서비스 : 파드 접속을 안정적으로 유지하도록 서비스를 통해 내/외부로 연결됨. 기존 인프라에서 로드밸런서, 게이트웨이와 비슷한 역할을 함.
디플로이먼트
효율적으로 작동하도록 기능들을 조합하고 추가해 구현한 것이 디플로이먼트.
디플로이먼트 삭제
디플로이먼트가 삭제됐는지 확인
많은 사용자를 대상으로 웹 서비스를 하려면 다수의 파드가 필요한데, 하나씩 생성한다면 매우 비효율적 -> 쿠버네티스에서는 다수의 파드를 만드는 레플리카셋 오브젝트를 제공
그러나, 레플리카셋은 파드 수를 보장하는 기능만 제공하기 때문에 디플로이먼트를 사용해 파드 수를 관리하는 것이 권장된다.
배포된 파드의 상태를 확인
nginx-pod를 3개로 증가시키기
-> 리소스를 찾을 수 없다는 에러 메시지가 나옴. 파드로 생성됐기 때문에 디플로이먼트 오브젝트에 속하지 않아서 발생하는 에러임.
디플로이먼트로 생성된 dpy-nginx의 파드의 수를 3개로 만들기
추가된 2개의 nginx 파드 확인
모든 파드가 정상적으로 워커 노드에 적용되고 IP가 부여됐는지 확인
생성한 디플로이먼트 dpy-nginx 삭제
삭제한 후에 배포된 파드 또는 디플로이먼트의 상태 확인
create에서 디플로이먼트를 생성하면서 한번에 여러 개의 파드를 만들기 위해서는 오브젝트 스펙 파일을 작성해서 설정을 적용해야 한다.
echo-hname.yaml 파일을 이용해 디플로이먼트를 생성
새로 생성된 echo-hname 파드가 3개인지 확인
echo-hname.yaml 파일을 수정해 파드를 6개로 늘리기
sed : 파일 수정해주는 명령어 / -i : 변경한 내용을 현재 파일에 바로 적용하겠다는 의미
replicas의 값이 3에서 6으로 변경됐는지 확인
변경된 내용을 적용
-> 이미 있다는 문구만 뜸
create로 디플로이먼트를 생성하면 파일의 변경 사항을 바로 적용할 수 없다는 단점이 있음. -> 쿠버네티스틑 apply라는 명령어를 제공함.
echo-hname.yaml 파일을 kubectl apply 명령으로 적용
6개로 늘어났는지 확인
-> 일회적 사용(애드혹)으로 오브젝트를 생성할 때는 create를 사용하고, 변경이 생길 가능성이 있는 복잡한 오브젝트는 파일로 작성한 후 apply로 적용하는 것이 좋음.
쿠버네티스는 거의 모든 부분이 자동 복구되도록 설계.
파드의 자동 복구 기술을 셀프 힐링이라고 함. -> 제대로 작동하지 않는 컨테이너를 다시 시작하거나 교체해 파드가 정상적으로 작동하게 함.
접속할 파드의 IP를 확인
파드 컨테이너의 셸에 접속하기
it 옵션 : 표준 입력을 명령줄 인터페이스로 작성한다는 의미 / 파드인 nginx-pod에 /bin/bash를 실행해 nginx-pod의 컨테이너에서 배시 셸에 접속
컨테이너에서 구동하는 nginx의 PID를 확인
프로세스가 생성된 시간을 확인
m-k8s의 터미널을 1개 더 띄우고 nginx-pod의 IP에서 돌아가는 웹 페이지를 1초마다 한 번씩 요청하는 스크립트를 실행
배시 셸에서 nginx 프로세서인 PID 1번을 종료
추가한 터미널에서 1초마다 nginx 웹 페이지를 받아오는 스크립트가 잘 작동하는지 확인하고 자동으로 다시 복구되는지도 함께 확인
배시셸에서 ls -l을 실행하여 nginx.pid가 생성된 시간으로 새로 생성된 프로세스인지 확인
exit 명령을 수행해 다시 m-k8x의 배시 셸로 나옴
쿠버네티스는 파드 자체에 문제가 발생하면 파드를 자동 복구해서 파드가 항상 동작하도록 보장하는 기능이 있음
파드에 문제가 발생하는 상황을 만들기 위해 앞에서 생성한 파드를 삭제하기 전에 현재 어떤 파드들이 있는지 먼저 확인
nginx-pod 삭제
파드 목록 중에서 가장 위에 있떤 파드를 삭제
삭제가 잘 됐는지 확인
-> 아직도 6개의 파드가 살아있으며 AGE를 봤을 때 하나는 최근에 생성된 것으로 보임. 또한 앞에서 삭제한 것은 목록에 없음.
nginx-pod는 디플로이먼트에 속한 파드가 아니며 어떤 컨트롤러도 이 파드를 관리하지 않기 때문에 바로 삭제되고 다시 생성되지도 않음.
echo-hname은 디플로이먼트에 속한 파드이고 replicas에서 6개로 선언했음. replicas는 파드를 선언한 수대로 유지하도록 파드의 수를 항상 확인하고 부족하면 새로운 파드를 만들어냄. 그렇기 때문에 삭제해도 1개가 생성됐던 것이다.
디플로이먼트에 속한 파드는 상위 디플로이먼트를 삭제해야 파드가 삭제됨. 디플로이먼트를 삭제하기
배포된 파드가 남아있는지 확인
노드는 쿠버네티스 스케줄러에서 파드를 할당받고 처리하는 역할을 함.
문제가 생길 가능성이 있는 노드라는 것을 쿠버네티스에 어떻게 알려줄까?
이런 경우에 cordon 기능을 사용한다.
echo-hname.yaml을 적용해 파드를 생성
배포한 파드를 9개로 늘리기
배포된 9개의 파드가 제대로 작동하는지, IP 할당이 잘 됐는지, 각 노드로 공평하게 배분됐는지를 확인
custom-columns : 사용자가 임의루 구성할 수 있는 열을 의미 / NAME, IP, STATUS, NODE는 열의 제목 / 콜론 뒤에 내용 값을 넣고 콤마로 구분
파드의 수를 3개로 줄이기
각 노드에 파드가 1개씩만 남았는지 확인
w3-k8s 노드에서 문제가 자주 발생해 현재 상태를 보존시키기.
cordon 명령이 제대로 적용됐는지 확인
-> w3-k8s가 더 이상 파드가 할당되지 않는 상태로 변경됨.
파드 수를 9개로 늘리기
노드에 배포된 파드를 확인
-> w3-k8s에 추가로 배포된 파드는 없음
파드 수를 3개로 줄이기
각 노드에 할당된 파드 수가 공평하게 1개씩인지 확인
w3-k8s에 파드가 할당되지 않게 설정했던 것을 해제
uncordon이 적용됐는지 확인
쿠버네티스를 사용하다 보면 정기 및 비정기적인 유지보수를 위해 노드를 꺼야 하는 상황이 발생함. 이런 경우를 대비해 쿠버네티스는 drain 기능을 제공.
drain은 지정된 노드의 파드를 전부 다른 곳으로 이동시켜 해당 노드를 유지보수할 수 있게 함.
drain은 실제로 파드를 옮기는 것이 아니라 노드에서 파드를 삭제하고 다른 곳에 다시 생성함. 그러나, DemonSet은 각 노드에 1개만 존재하는 파드라서 drain으로는 삭제할 수 없음.
노드 w3-k8s에 파드가 없는지 확인. 옮긴 노드에 파드가 새로 생성돼 파드 이름과 IP가 부여된 것도 확인
w3-k8s 노드의 상태를 확인
유지보수가 끝났다고 가정하고 w3-k8s가 스케줄을 받을 수 있는 상태로 복귀시키기
다시 노드 상태를 확인
배포한 echo-hname을 삭제
배포된 파드가 없음을 확인
파드 업데이트하기
record 옵션으로 기록된 히스토리 확인
배포한 파드의 정보를 확인
배포된 파드에 속해 있는 nginx 컨테이너 버전을 확인
파드의 nginx 컨테이너 버전을 1.16.0으로 업데이트하기 + --record도 사용
파드의 상태를 확인
-> 파드들의 이름과 IP가 변경됨
파드에 속한 nginx 컨테이너를 업데이트하는 가장 쉬운 방법은 파드를 관리하는 replicas의 수를 줄이고 늘려 파드를 새로 생성하는 것이라서 이렇게 변경되는 거임.
Deployment 상태를 확인
rolout-nginx에 적용된 명령들을 확인
업데이트가 제대로 이루어졌는지도 확인
업데이트 실패 시 파드 복구하기
nginx 컨테이너 버전을 의도(1.17.2)와 다르게 1.17.23을 입력
상태 확인
-> 파드가 삭제되지 않고 pending(대기 중) 상태에서 넘어가지 않음
복구하기 위해 업데이트할 때 사용했던 명령들을 확인
명령 실행을 취소해 마지막 단계에서 전 단계로 상태를 되돌림
파드 상태를 다시 확인
실행된 명령을 확인
-> revision 4가 추가되고 revision 2가 삭제됨. 현재 상태를 2로 되돌렸기 때문에 2는 삭제되고 가장 최근 상태는 4가 됨
배포된 컨테이너의 nginx 버전 확인
변경이 정상적으로 적용됐는지 확인
현재 디플로이먼트 상태도 세부적으로 점검
특정 시점으로 파드 복구하기
처음 상태인 revision 1로 돌아가보기
새로 생성된 파드들의 IP를 확인
nginx 컨테이너의 버전을 확인
-> 처음 상태로 복구됨
rollout-nginx 디플로이먼트 삭제
배포된 파드가 없는지 확인
서비스 : 쿠버네티스에서 외부에서 쿠버네티스 클러스터에 접속하는 방법
노드포트 서비스를 설정하면 모든 워커 노드의 특정 포트(노드 포트)를 열고 여기로 오는 모든 요청을 노드포트 서비스로 전달함. -> 노드포트 서비스는 해당 업무를 처리할 수 있는 파드로 요청을 전달함.
노드포트 서비스로 외부에서 접속하기
디플로이먼트로 파드를 생성
배포된 파드를 확인
노드포트 서비스 생성 (편의를 위해 이미 정의한 오브젝트 스펙을 이용)
nodeport.yaml에서 kind가 Service로 바뀌었고 서비스의 type을 NodePort로 지정함
쿠버네티스 클러스터의 워커 노드 IP를 확인
웹 브라우저를 띄우고 확인한 워커 노드의 IP와 노드포트의 포트번호인 30000번으로 접속해 외부에서 접속되는지 확인
-> 배포된 파드에 모든 노드의 노드포트를 통해 외부에서도 접속할 수 있음을 확인
부하 분산 테스트하기
cmd 창을 띄우고 해당 명령 실행
마스터노드에서 파드를 3개로 증가시키기
배포된 파드를 확인
파워셸 명령 창을 확인해 표시하는 파드 이름에 배포된 파드 3개가 돌아가면서 표시되는지 확인
-> 부하 분산이 제대로 되고 있음
노드포트의 오브젝트 스펙에 적힌 np-pods와 디플로이먼트의 이름을 확인해 동일하면 같은 파드라고 간주했기 때문에 추가된 파드를 외부에서 추적해 접속하는 것임.
expose로 노드포트 서비스 생성하기
서비스로 내보낼 디플로이먼트를 np-pods로 지정. 해당 서비스의 이름은 np-svc-v2로, 타입은 NodePort로 지정, 연결 포트를 80번으로 지정
생성된 서비스를 확인
-> expose를 사용하면 노드포트의 포트 번호를 지정할 수 없음. 포트 번호는 30000~32767에서 임의로 지정됨.
여러 개의 디플로이먼트가 있을 때 그 수만큼 노드포트 서비스를 구동할 순 없기 때문에 이런 경우에 인그레스를 사용함.
인그레스 : 고유한 주소를 제공해 사용 목적에 따라 다른 응답을 제공할 수 있고, 트래픽에 대한 L4/L7 로드밸런서와 보안 인증서를 처리하는 기능을 제공
인그레스를 사용하려면 인그레스 컨트롤러가 필요함. 여기서는 NGINX 인그레스 컨트롤러로 구성함.
[NGINX 인그레스 컨트롤러가 작동하는 단계]
1. 사용자는 노드마다 설정된 노드포트를 통해 노드포트 서비스로 접속함. 이때 노드포트 서비스를 NGINX 인그레스 컨트롤러로 구성
2. NGINX 인그레스 컨트롤러는 사용자의 접속 경로에 따라 적합한 클러스터 IP 서비스로 경로를 제공
3. 클러스터 IP 서비스는 사용자를 해당 파드로 연결해 줌
테스트용으로 디플로이먼트 2개(in-hname-pod, in-ip-pod)를 배포
배포된 파드의 상태 확인
NGINX 인그레스 컨트롤러를 설치
NGINX 인그레스 컨트롤러의 파드가 배포됐는지 확인 ingress-nginx 네임스페이스에 속하므로 옵션을 추가함.
인그레스를 사용자 요구 사항에 맞게 설정하기 위해 경로와 작동을 정의
ingress-config.yaml은 들어오는 주소 값과 포트에 따라 노출된 서비스를 연결하는 역할을 설정. 외부에서 주소 값과 노드포트를 가지고 들어오는 것은 hname-svc-default 서비스와 연결된 파드로 넘기고, 외부에서 들어오는 주소 값, 노드포트와 함께 뒤에 /ip를 추가한 주소값은 ip-svc 서비스와 연결된 파드로 접속하게 설정
인그레스 설정 파일이 제대로 등록 됐는지 확인
인그레스에 요청한 내용이 확실하게 적용됐는지 확인
-> 인그레스에 적용된 내용을 야믈 형식으로 출력해 적용된 내용을 확인할 수 있음
노드포트 서비스로 생성된 NGINX 인그레스 컨트롤러를 확인
디플로이먼트도 서비스로 노출하기. (외부와 통신하기 위해 클러스터 내부에서만 사용하는 파드를 클러스터 외부에 노출할 수 있는 구역으로 옮기는 것)
생성된 서비스들을 점검해 디플로이먼트들이 서비스에 정상적으로 노출되는지 확인
웹 브라우저를 띄우고 192.168.1.101:30100에 접속
192.168.1.101:30100/ip에 접속
-> 요청 방법과 파드의 ip가 반환됨
https://192.168.1.101:30101로 접속해 HTTPS 연결도 정상적으로 작동하는지 확인
https://192.168.1.101:30101/ip를 입력해 접속되는지 확인
배포한 디플로이먼트와 모든 서비스를 삭제
NGINX 인그레스 컨트롤러와 관련된 내용도 모두 삭제
앞선 방식들은 매우 비효율적임.
그래서 쿠버네티스에서는 로드밸런서라는 서비스 타입을 제공해 간단한 구조로 파드를 외부에 노출하고 부하를 분산함.
지금까지 로드밸런서를 사용하지 않은 이유는 이를 사용하려면 로드밸런서를 이미 구현해 둔 서비스 업체의 도움을 받아 쿠버네티스 클러스터 외부에 구현해야 하기 때문임.
-> 우리가 만든 테스트 가상 환경에서 로드밸런서 사용방법을 알아볼 예정
MetalLB : 온프레미스에서 로드밸런서를 사용하기 위해 내부에 로드밸런서 서비스를 받아주는 구성을 지원하는 것. 특별한 네트워크 설정이나 구성이 있는 것이 아니라 기존의 L2 네트워크와 L3 네트워크로 로드밸런서를 구현함.
이 책에서는 MetalLB의 L2 네트워크로 로드밸런서를 구현함.
MetalLB 컨트롤러는 작동 방식인 프로토콜을 정의하고 EXTERNAL-IP를 부여해 관리함. MetalLB 스피커는 정해진 작동 방식에 따라 경로를 만들 수 있도록 네트워크 정보를 광고하고 수집해 각 파드의 경로를 제공함.
디플로이먼트를 이용해 2종류(lb-hname-pods, lb-ip-pods)의 파드를 생성하고 파드를 3개로 늘려 노드당 1개씩 파드가 배포되게 함.
2종류의 파드가 3개씩 총 6개가 배포됐는지 확인
사전에 정의된 오브젝트 스펙으로 MetalLB를 구성. 필요한 요소가 모두 설치되고 독립적인 네임스페이스(metallb-system)도 함께 만들어짐
배포된 MetalLB의 파드가 5개인지 확인하고, IP와 상태도 확인
MetalLB에 설정 적용 (오브젝트는 ConfigMap을 사용 - 설정이 정의된 포맷)
ConfigMap이 생성됐는지 확인
옵션을 주고 다시 실행해 MetalLB의 설정이 올바르게 적용됐는지 확인
각 디플로이먼트(lb-hname-pods, lb-ip-pods)를 로드밸런서 서비스로 노출하기
생성된 로드밸런서 서비스별로 CLUSTER-IP와 EXTERNAL-IP가 잘 적용됐는지 확인. 특히 EXTERNAL-IP에 ConfigMap을 통해 부여한 IP를 확인
웹 브라우저에서 192.168.1.11로 접속
웹 브라우저에 192.168.1.12로 접속해 파드에 요청 방법과 IP가 표시되는지 확인
파워셸 명령 창을 띄우고 셸 스크립트 실행
파드를 6개로 늘리기
늘어난 파드 6개도 EXTERNAL-IP를 통해 접근되는지 확인
배포한 디플로이먼트와 서비스는 삭제. 단, MetalLB 설정은 계속 사용하므로 삭제하지 않음
쿠버네티스는 사용자가 갑자기 늘어나는 경우를 대비해 부하량에 따라 디플로이먼트의 파드 수를 유동적으로 관리하는 기능을 제공함. 이것을 HPA라고 한다.
디플로이먼트 1개를 hpa-hname-pods라는 이름으로 생성
hpa-hname-pods를 로드밸런서 서비스로 바로 설정
설정된 로드밸런서 서비스와 부여된 IP를 확인
부하를 확인
-> 자원을 요청하는 설정이 없다며 에러가 생기고 진행되지 않음.
HPA가 자원을 요청할 때 메트릭 서버를 통해 계측값을 전달받음. but, 현재 우리에게는 메트릭 서버가 없기 때문에 에러가 발생하는 것임. 메트릭 서버를 설정해야 한다!
오브젝트 스펙 파일로 메트릭 서버 생성
부하를 다시 확인
-> 현재는 아무런 부하가 없으므로 CPU와 MEMORY 값이 매우 낮게 나옴
왼쪽에 마스터 노드 창 두 개를 띄우고 오른쪽에는 파워셸 창 띄우기
왼쪽 상단 창에서는 watch kubectl top pods. 하단 창에서는 watch kubectl get pods를 실행.
watch 사용 이유 : 2초에 한 번씩 자동으로 상태를 확인하기 위해
파워셸 창에서 반복문 실행
왼쪽 상단 창에서 부하량을 감지하는지 확인
부하량이 늘어남에 따라 왼쪽 하당 창에서 파드가 새로 생성되는지 확인
부하 분산으로 생성된 파드의 부하량이 증가하는지 확인
더 이상 파드가 새로 생성되지 않는 안정적인 상태가 되는 것일 확인하고 파워셸 창을 종료
더이상 부하가 없으면 autoscale의 최소 조건인 파드 1개의 상태로 돌아가기 위해 파드가 종료되는 것을 확인 -> 1개만 남음
생성한 디플로이먼트, 서비스, 메트릭 서버를 삭제 (MetalLB는 삭제하지 않음)
데몬셋은 디플로이먼트의 replicas가 노드 수 만큼 정해져 있는 형태임.
노드를 관리하는 파드라면 데몬셋으로 만드는 게 가장 효율적이다.
현재 MetalLB의 스피커가 각 노드에 분포돼 있는 상태를 확인
워커 노드를 1개 늘리기 (Vagrantfile의 5번째 줄에 있는 N 인자의 값을 3에서 4로 수정)
w4-k8s를 실행 (새로운 워커 노드를 추가하는 명령)
m-k8s에서 확인
자동으로 추가된 노드에 설치된 스피커가 데몬셋이 맞는지 확인
컨피그맵은 설정을 목적으로 사용하는 오브젝트. MetalLB는 프로젝트 타입으로 정해진 오브젝트가 없어서 범용 설정으로 사용되는 컨피그맵을 지정했음.
테스트용 디플로이먼트를 cfgmap이라는 이름으로 생성
cfgmap을 로드밸런서를 통해 노출하고 이름은 cfgmap-svc로 지정
생성된 서비스의 IP를 확인
사전에 구성돼 있는 컨피그맵의 기존 IP를 sed 명령을 사용해 192.168.1.21~192.168.1.23으로 변경
컨피그맵 설정 파일에 apply를 실행해 변경된 설정을 적용
MetalLB와 관련된 모든 파드를 삭제 -> 삭제하고나면 kubelet에서 해당 파드를 자동으로 모두 다시 생성
새로 생성된 MetalLB의 파드들을 확인
기존에 노출한 MetalLB 서비스를 삭제하고 동일한 이름으로 다시 생성해 새로운 컨피그맵을 적용한 서비스가 올라오게 함
변경된 설정이 적용돼 새로운 MetalLB 서비스의 IP가 192.168.1.21로 바뀌었는지 확인
웹브라우저에서 192.168.1.21로 접속해 파드의 이름이 화면에 표시되는지 확인
생성한 디플로이먼트와 서비스를 삭제
때때로 파드에서 생성한 내용을 기록하고 보관하거나 모든 파드가 동일한 설정 값을 유지하고 관리하기 위해 공유된 볼륨으로부터 공통된 설정을 가지고 올 수 있도록 설계해야 할 때가 있음. 이런 경우를 위해 다양한 형태의 볼륨을 제공함. 이책에서는 다양한 쿠버네티스 볼륨 스토리지 중에서 PV와 PVC를 설명함.
쿠버네티스틑 필요할 때 PVC(지속적으로 사용 가능한 볼륨 요청)을 요청해 사용. PVC를 사용하려면 PV(지속적으로 사용 가능한 볼륨)로 볼륨을 선언해야 함.
-> PV는 볼륨을 사용할 수 있게 준비하는 단계, PVC는 준비된 볼륨에서 일정 공간을 할당 받는 것.
가장 구현하기 쉬운 NFS 볼륨 타입으로 PV와 PVC를 생성하고 파드에 마운트해 볼 예정.
NFS 볼륨에 PV/PVC 만들고 파드에 연결하기
PV로 선언할 볼륨을 만들기 위해 NFS 서버를 마스터 노드에 구성.
해당 내용을 시스템에 적용해 NFS 서버를 활성화하고 다음에 시작할 때도 자동으로 적용되도록 하기
다음 경로에 있는 오브젝트 스펙을 실행해 PV를 생성
생성된 PV의 상태가 사용 가능임을 확인
다음 경로에서 오브젝트 스펙을 실행해 PVC를 생성
생성된 PVC를 확인. PV와 PVC가 연결됐음을 의미하는 Bound확인.
PV의 상태도 Bound로 바뀌었음을 확인
생성한 PVC를 볼륨으로 사용하는 디플로이먼트 오브젝트 스펙을 배포
생성한 파드 중 하나에 exec로 접속
로드밸런서 서비스를 생성
kubectl expose deployment nfs-pvc-deploy --type=LoadBalancer --name=nfs-pvc-deploy-svc --port=80
NFS 볼륨을 파드에 직접 마운트하기
nfs-ip.yaml 생성
설치한 PV와 PVC를 제외한 나머지 파드와 서비스를 삭제
스테이트풀셋은 volumeClaimTemplates 기능을 사용해 PVC를 자동으로 생성할 수 있고, 각 파드가 순서대로 생성되기 때문에 고정된 이름, 볼륨, 설정 등을 가질 수 있습니다. 그러나, 효율성 면에서 좋은 구조가 아니므로 요구 사항에 맞게 적절히 사용해야 함.
스테이트풀셋 생성
파드가 생성되는지 확인
로드밸런서 서비스를 작성 및 실행
로드밸런서 서비스 확인
스테이트풀셋의 파드 삭제
쿠버네티스 클러스터에서도 도메인 이름을 이용해 통신한다는 것을 처음 알게 되었다. IP주소로만 통신한다고 생각했는데, 어찌보면 당연한 일인데도 신기했다. 실무에서는 CoreDNS를 사용해서 도메인 이름을 이용해 통신하는 데에 사용한다고 하는데, IP 주소가 아니라 도메인 이름으로 통신 할 수 있으니 더 편리하겠다는 생각이 들었다.
디플로이먼트에 속한 파드를 삭제 하기 위해서는 상위 디플로이먼트를 삭제해야 파드가 삭제된다는 것을 알게 되었다.
우리가 서버가 터지면 aws에서 ec2 서버를 재시작하듯이 쿠버네티스에서도 그러한 문제가 발생했을 때 방안들이 많이 마련되어있는 것 같아서 좋은 것 같다. 예로들어 우리도 어떠한 문제가 발생해서 파드를 업데이트하거나 복구시킬 때 record 옵션로 히스토리를 이용해서 손쉽게 업데이트하거나 복구할 수 있겠다는 생각이 들었다.