귀염둥이의 메모

Why Volume? 컨테이너는 기본적으로 stateless 앱 컨테이너를 사용한다. 상태가 없기 때문에 노드에 장애가 발생했을 때 다른 노드로 자유롭게 옮길 수 있는 장점을 가진다. 하지만 어떠한 이유로든 컨테이너가 실행되지 않거나 삭제되었을 때, 현재까지 저장된 데이터는 사라진다는 단점이 있다. 특성에 따라서 컨테이너에 문제가 발생하더라도 데이터 보존이 필요한 경우가 있다. 이런 상황에서 볼륨(Volume)을 사용한다. 예를 들어 MySQL 같은 DB는 컨테이너는 종료하거나 재시작했을 때 저장된 데이터가 사라지면 치명적이다. PV(Persistent Volume)를 사용하면 기존에 데이터를 저장했던 노드가 아닌 다른 노드에서 컨테이너를 재시작하더라도 데이터를 저장한 볼륨을 그대로 사용할 수 있다. 볼..

롤링 업데이트 (RollingUpdate) 디플로이먼트의 기본 배포 방법 배포된 전체 파드를 한꺼번에 교체하는 것이 아닌 일정 개수씩 교체하면서 배포하는 방식 파드를 하나씩 죽이고 새로 띄우는 순차적인 교체 방법 업데이트 프로세스 동안 두 가지 버전의 컨테이너가 동시에 실행되어서 버전 호환성 문제가 발생 가능 블루/그린 (Blue/Green) 기존에 실행된 파드 개수만큼 신규 파드를 모두 실행한다 신규 파드가 정상적으로 실행되면 한꺼번에 트래픽을 옮기는 방식 신버전과 구버전이 같이 존재하는 시간 없이 순간적인 교체 가능 롤링 업데이트보다 필요한 리소스 양이 많음 카나리 (Canary) 기존 버전을 유지한 채로 일부 버전만 신규 파드로 교체 (한꺼번에 전체 교체 X) 구버전과 신버전이 같이 존재한다 버그 ..

kubectl version : 버전 확인 kubectl cluster-info : 클러스터 정보 확인 kubectl run ~ : 단순히 파드를 실행할 때 (이미지 지정) kubectl expose ~ : 서비스를 명령어로 생성 kubectl create ~ : 컨트롤러를 명령어로 생성 kubectl apply ~ : 템플릿으로 재설정/생성 kubectl edit ~ : 동작 중인 설정을 변경할 때 사용 kubectl delete ~ : 리소스 제거 kubectl get ~ : 리소스 기본 정보 확인 kubectl describe ~ : 리소스 상세 정보 확인 kubectl explain ~ : 템플릿 속성 값 확인

레이블(Label) key-value 쌍으로 구성하며, 사용자가 클러스터 안에 오브젝트를 만들 때 메타데이터로 설정할 수 있다. 레이블이 생성된 다음에도 언제든지 수정이 가능하다. key는 쿠버네티스 안에서 컨트롤러들이 파드를 관리할 때 자신이 관리해야 할 파드를 구분하는 역할을 한다. 레이블만으로 관리 대상을 구분하기 때문에 특정 컨트롤러가 만든 파드라도 레이블을 변경하면 인식할 수 없다. 컨트롤러와 파드를 느슨하게 결합하는 특징 때문에 파드들을 유연하게 관리 가능하다. 특정 레이블을 선택할 때는 셀렉터(Selector)를 사용한다. 등호 기반은 '='또는 '==', '!=' 연산자를 사용하여 같은지 다른지 구분 가능하다. 레이블 설정 규칙 63글자를 넘지 않아야 함 시작과 끝 문자는 알파벳 대소문자 ..

서비스(Service) 서비스는 여러 개의 파드에 접근할 수 있는 IP 하나를 제공한다. 파드가 클러스터 안 어디에 있든 고정 주소를 이용해 접근이 가능하다. L4 영역에서 통신할 때 사용 파드에 접근할 수 있는 경로 제공 고정된 포인트 / 외부 접근 가능한 포인트를 제공 서비스에는 크게 4가지 종류가 있다 ClusterIP : 기본 서비스 타입이며 클러스터 내부에서만 사용할 수 있다. 클러스터 내부 노드나 파드에서는 클러스터 IP를 이용해서 서비스에 연결된 파드에 접근한다. 클러스터 외부에서는 이용 불가❌ NodePort : 서비스 하나에 모든 노드의 지정된 포트를 할당한다. node1:8080, node2:8080처럼 노드에 상관없이 서비스에 지정된 포트 번호만 사용하여 파드에 접근할 수 있다. 노드..

Master Node = Control-Plane 클러스터를 관리하는 역할을 한다 etcd, kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy, docker 등이 실행된다 고가용성을 위해서 3대 이상으로 운영하기도 한다 Worker Node = Node 실제 컨테이너를 실행시키는 작업을 한다 kubelet, kube-proxy, docker 등이 실행된다 Master Node와 Worker Node의 통신 쿠버네티스의 모든 통신의 중심에는 apiserver가 있다. apiserver를 통해서 다른 프로세스들이 서로 필요한 정보를 주고받는다. etcd에 대한 접근은 apiserver만 가능하다. 마스터 서버를 보면 ku..

kube-proxy 서비스를 만들었을 때 ClusterIP나 NodePort로 접근할 수 있게 만들어 실제 조작을 하는 컴포넌트 클러스터의 노드마다 실행되면서 클러스터 내부 IP로 연결하려는 요청을 적절한 파드로 전달 userspace, iptables, IPVS 모드가 있다 userspace 모드 클라이언트에서 서비스의 ClusterIP를 통해 요청을 하면 iptables를 거쳐 kube-proxy가 요청을 받는다 그리고 서비스의 ClusterIP는 연결되어야 하는 적절한 파드로 연결해준다 요청을 파드로 연결하는 방식은 라운드 로빈(Round Robin)을 사용한다 파드 하나로의 연결 요청이 실패하면 자동으로 다른 파드에 연결을 재시도한다 iptables 모드 userspace와 다르게 kube-pro..

사이드카 패턴(Sidecar) 원래 사용하려던 기본 컨테이너의 기능을 확장하거나 강화하는 용도의 컨테이너를 추가하는 것 기본 컨테이너는 원래 목적에만 충실하도록 구성 나머지 공통 부가 기능들은 사이드카 컨테이너를 추가해서 사용 공통 역할을 하는 컨테이너의 재사용성을 높일 수 있음 앰배서더 패턴(Ambassador) 파드 안에서 프록시 역할을 하는 컨테이너를 추가하는 패턴 파드 안에서 외부 서버에 접근할 때 내부 프록시에 접근하도록 설정 실제로 외부와 연결은 프록시가 알아서 처리함 어댑터 패턴(Apdater) 파드 외부로 노출되는 정보를 표준화하는 어댑터 컨테이너를 사용 주로 어댑터 컨테이너로 파드의 모니터링 지표를 표준화한 형식으로 노출시키고, 외부의 모니터링 시스템에서 해당 데이터를 주기적으로 가져가서..

프로브(Probe) 프로브는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단이다. 진단을 수행하기 위해서, kubelet은 컨테이너에 의해서 구현된 핸들러를 호출한다. ExecAction : 컨테이너 안에 지정된 명령을 실행하고 종료 코드가 0일 때 Success라고 진단 TCPSocketAction : 컨테이너 안에 지정된 IP와 포트로 TCP 상태를 확인하고 포트가 열려있으면 Success라고 진단 HTTPGetAction : 컨테이너 안에 지정된 IP, 포트, 경로로 HTTP GET 요청하고 응답 코드가 200 ~ 400 이면 Success라고 진단 진단 결과 Success : 진단에 성공 Failure : 진단에 실패 Unknown : 진단 자체가 실패해서 컨테이너 상태를 알 수 없음 ..

Kubespray Kubeadm 과 Ansible을 이용한 쿠버네티스 클러스터 배포 도구 별도의 로드 밸런서를 사용하지 않고 노드 각각의 nginx가 리버스 프록시로 실행됨 nginx-proxy가 전체 마스터 노드를 바라보는 구조 control-plane에서 설정 및 설치 # 약어 등록하기 sudo vim /etc/hosts ssh-keygen ssh-copy-id control-plane ssh-copy-id node1 ssh-copy-id node2 # vagrant 유저는 sudo 권한이 있음 sudo apt update # 현재 가지고있는 패키지들의 새로운 버전 리스트 구성 sudo apt upgrade -y # 이 명령어를 해야지 실제로 최신버전으로 업데이트 됨 sudo apt install p..