컨테이너 인프라환경이 대두되면서 그 컨테이너들은 관리해야할 필요가 생김(오케스트레이션)
- 오케스트레이션:복잡한 단계를 관리하고 요소들의 유기적인 관계를 미리 정의해 손쉽게 사용하도록 서비스를 제공(다수의 컨테이너를 연결,실행,종료,상태 추적 등등)
그 후 구글에서 쿠버네티스를 오픈소스로 공개 하고 쿠버네티스가 인프라환경의 표준이되었다.
쿠버네티스의 핵심 설계 사상
1. 선언적 구성 기반의 배포 환경
k8s에서는 동작을 지시하는 개념(예: 레플리카를 5개 만들어라)보다는 원하는 상태를 선언하는 개념(예: 내 호스트의 레플리카를 항상 5개로 유지하라)을 주로 사용한다.
원하는 상태(Desired state)와 현재의 상태(Current state)가 상호 일치하는지를 지속적으로 체크하고 업데이트한다.
2.기능 단위의 분산
쿠버네티스에서는 각각의 기능들이 개별적인 구성 요소로서 독립적으로 분산되어 있다.
쿠버네티스는 내부 요소들의 상태 관리를 위해 컨트롤러를 이용한다.
3. 동적 그룹화
레이블 기준으로 구성 요소들을 유연하게 관리할 수 있고, 어노테이션에 기재된 내용을 참고하여 해당 요소의 특징적인 내역을 추적할 수 있다.
4. API 기반 상호작용
쿠버네티스 요소들이 서로 직접 접근 불가,
Kubernetes API server(kube-apiserver)를 통해서만 상호 접근이 가능한 구조를 가진다.
쿠버네티스 구성
쿠버네티스 클러스터란?
- 효율적인 리소스 공유와 균형 배분을 위해 여러 노드를 묶은 그룹
- 워커 노드는 애플리케이션의 구성요소인 파드(컨테이너) 를 호스트
- 컨트롤 플레인은 워커 노드와 클러스터 내 파드를 관리
4.1. 마스터(master)
1) Controller
서버 관리에서 state(상태)의 종류는 다양할 수 있다. 쿠버네티스에서는 클러스터 상태의 각 특정한 부분을 관리하는 많은 컨트롤러 를 사용한다. 쿠버네티스 디자인 원리의 핵심이기도 한데, 상태를 제어할 때 루프가 하나로 연결되어 있는 모놀리식(monolithic) 집합보다 간단하게 컨트롤러를 여러 개 사용하는게 편리하기 때문이다.
기능별로 쪼개고 추상화했기 때문에 각각의 기능을 관리하기가 편해지는 것이고, 이를 통해 관리 자동화를 실현할 수 있게 된다.
2) Scheduler
CPU 또는 메모리와 같은 포드(컨테이너의의 집합이자 쿠버네티스 애플리케이션의 최소 단위)의 리소스 요구 사항과 함께 클러스터의 상태를 고려한다. 그런 다음 포드를 적절한 컴퓨팅 노드에 예약한다. 쉽게 말해서 여유있는 서버를 찾아 컨테이너를 어디에 띄울지 결정하는 것.
3) etcd
상태를 저장하고 조회하는 DB인 엣지디(etcd)가 있다. etcd는 모든 상태와 데이터를 확실하게 저장해야한다. 따라서 백업은 필수이며, 아래 같은 특징을 가지고 있다.
고가용성 : 분산 시스템으로 구성하여(보통 엣지디를 3대정도 띄운다고 한다) 안정성을 높임
일관성 : 가볍고 빠르면서 정확하게 설계
key-value 형태로 데이터 저장
TTL(time to live), watch 등 부가기능 제공
4) API server
마스터의 조율자 역할을 하는 API Server 이다. 데이터와 상태를 조회하거나 변경하는 요청은 모두 API 서버를 통해(거쳐서) 이뤄진다. 아래와 같은 특징을 가지고 있다.
상태를 바꾸거나 조회
ectd와 유일하게 통신하는 모듈
권한 체크 (권한이 없으면 요청 거부)
REST API
4.2. 노드(node)
노드에는 크게 두 가지 컴포넌트가 떠있는데, 프록시(Proxy)와 큐블릿(Kubelet) 이다. 이 두 컴포넌트도 마스터와 통신을 할 때 API Server를 통해서만 요청와 응답를 얻을 수 있다.
1) Proxy
네트워크 프록시 역할(부하 분산)을 하긴 하지만 실제로 요청/응답을 받는 프록시가 떠있는 개념은 아니고, 내외부 통신 설정만 관리하는 역할을 한다.
iptables 또는 IPVS를 사용한다.
2) Kubelet
각 노드에서 실행되며, pod를 실행하거나 중지하고 상태를 체크한다. 도커 등 아니라 다양한 CRI(Container Runtime Interface), 즉 컨테이너를 pod로 감싸 확실하게 관리하는 임무를 가지고 있는 것이다.
네임스페이스
다음의 명령어로 쿠버네티스의 네임스페이스를 확인 가능
kubectl get pods -n kube-system간단한 쿠버네티스 명령어들
kubectl get nodes =get = 자원보기 (get pods 는 pods를 본다)
kubectl run container –image <이미지 이름> –port <port번호> 실행할컨테이너 =컨테이너 실행하기
kubectl exec -it <pod> –- /bin/bash :파드 컨테이너의 쉘에 접속
kubectl drain 지정된 노드의 파일을 전부 다른곳으로 이동시켜 해당 노드를 유지보수 할 수있게함 (포드에서 삭제하고 다른곳에 다시 생성하는 방식) (kubectl uncordon 으로 복구)
kubectl apply -f <포드> –record = –record 히스토리남기기
kubectl describe deployment <포드>;파드의 문제점 상세하게 보기
kubectl rollout history deployment <포드>:파드 역사보기
kubectl rollout undo deployment <포드> 전버전으로 돌리기
kubectl rollout undo deployment <포드> –to-revision=1 1번째버전으로 돌리기
kubectl expose pod nginx –type=NodePort –port=80 노드포트를 이용해 80번을 외부로 노출
kubectl scale deployment <포드> –replicase=3 = pod를 3개만큼 생성
kubectl delete =지우기코드 관련 명령어
kubectl get pod nginx -o yaml =해당 파일의 yaml파일 출력
kubectl run nginx --image=nginx --dry-run=client -o yaml > po-nginx.yaml
= run할것을 yaml파일로 만들기
kubectl create deploy nginx --image=nginx -o yaml --dry-run=client > de-nginx.yaml
트러블 슈팅 관련 명령어
이벤트
kubectl get event :디폴트 네임스페이스의 이벤트들 확인
kubectl get events -n kube-system :해당 네임스페이스의 이벤트를 확인잘 안씀.
describe (설명하다)
kubectl describe pod nginx :배포된 오브젝트의 상태 파악logs
kubectl logs nginx : 컨테이너의 로그 파악요약 :
네임스페이스 : events
일반적인 오브젝트 (제일많이씀) :describe
컨테이너 : logs
Deployment란?
파드와 레플리카셋에대한 선언적 업데이트
기본적으로 쿠버네티스는 파드가 언제든지 죽을수 있는것이라고 인식을한다.
때문에, 파드가 죽으면 복구할수있도록 설계되어있다.
ex ) Deployment화를 하지 않은 파드가 있을경우
kubectl delete pod <그냥파드>
kubectl get pods : 파드들 확인하기하면 파드가 지워져있다 하지만 Deployment화된 파드를 지울경우 지워지지않고 다시 파드가 생성된다.
Deplyment화된 파드를 지우고 싶으면 추가적인 명령어가 필요하다
kubectl delete deployment <deployment화된 파드>쿠버네티스의 에러처리
워커노드의 Kubelet
systemlctl stop kubelet
대부분의 쿠버네티스 구성요소는 스스로 에러복구가 가능함.
하지만 Kubelet은 선언형으로 동작되지않기때문에 자동 에러복구가 되지않음
워커노드에서 kubelet에 문제가 생기면 마스터로드는 그 워커노드에 배포하지않음
systemlctl start kubelet로 복구를해주면 자동으로 그곳에 복구가됨
워커노드의 컨테이너 런타임
systemctl stop containerd컨테이너 런타임이 멈춘 워커노드에는 파드의 배포를 하지않음
스케쥴러가 컨테이너런타임이 멈춘것을 파악해 다른곳에 파드를 배포함,
마스터노드의 에러처리
기본적으로 스케쥴러같은 중요 서비스가 멈춰도 자동으로 복구가 된다.
마스터노드의 Kubelet이 멈추면 마스터노드의 노드의 상태를 확인 할수 없다.(실제로 실행은 되있음)
하지만 컨테이너D가 멈춰있을때 중요서비스가 멈추면 복구가 되지않는다.
