파드
생성
kubectl run [pod name][image name] : ex) kubectl run nginx-pod --image=nginx
kubectl create deployment [deployment name][image name] :
ex) kubectl create deployment deployment-nginx --image=nginx
run, create 의 차이점
run : 단일 파드 생성 및 관리
create : deployment 그룹 내에 파드 생성
조회
kubectl get pods(or pod 같은 의미로 인식) -o wide
-o : output 약어, 출력을 특정 형식으로 해주는 옵션
wide : 출력 형식에서 더 많은 정보를 표시해주는 옵션
삭제
kubectl delete pod [pod name] : kubectl delete pod nginx-pod
오브젝트
파드
쿠버네티스에서 실행되는 최소 단위, 웹 서비스를 구동하기 위한 최소 단위
범용적으로 1개의 파드는 1개의 컨테이너를 적용하나 여러개의 컨테이너를 가질 수 있음
네임스페이스
쿠버네티스 클러스터에서 사용되는 리소스를 구분하여 관리하는 그룹
볼륨
파드가 생성될 때 파드에서 사용할 수 있는 디렉터리 제공
파드는 영속의 개념이 아니기 때문에 디렉터리도 임시로 사용
파드가 사라져도 볼륨 오브젝트를 통해 저장과 보존이 가능한 디렉터리 사용 가능
서비스
파드의 접속 정보는 변할 수 있으며 안정적인 파드 접속을 위해 서비스를 통해 내/외부 연결
파드가 생성될 때 새로 부여되는 IP 를 기존에 제공하던 기능과 연결
이는 쿠버네티스가 외부에서 쿠버네티스 내부로 접속할 때 내부가 어떤 구조로 되어 있고
파드에 생존 유무를 알고있을 필요가 없어진다
로드밸런서, 게이트웨이와 비슷한 역할
로드밸런서 : 부하분산 또는 로드 밸런싱, 다수의 중앙처리장치, 저장장치 같은 컴퓨터 자원에 작업을 나눔
게이트웨이 : 네트워크에서 서로 다른 통신망, 프로토콜을 사용하는 네트워크 간의 통신을 가능하게 하는 것
디플로이먼트
기본 오브젝트의 한계를 효율적으로 작동하도록 기능들을 조합하고 추가하여 구현한 오브젝트
쿠버네티스에서 가장 많이 쓰이는 오브젝트로 파드를 기반으로 두며 레플리카셋 오브젝트를 합쳐 놓은 형태
레플리카셋으로 파드 수 관리
레플리카셋 : 파드 개수 보장
디플로이먼트 : 파드 수 관리
파드 3개 생성
kubectl get pods 입력 시 nginx-pod 라는 이름의 파드가 있다고 가정하에
kubectl scale pod nginx-pod --replicas=3
nginx-pod 가 디플로이먼트(그룹)로 생성되지 않고 파드(단일)로 생성된 경우 위 명령어는 작동하지 않음
kubectl get pods -o wide 로 생성된 3개의 파드 확인 및 deployment 다시 제거
kubectl delete deployment nginx-pod
오브젝트 스펙
metadata-name : 파드의 이름
kind : 파드
spec-하위 : 파드에서 호출할 컨테이너, 이미지 지정
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
name: container-name
image: nginx오브젝트 스펙을 이용한 파드 생성
kubectl create -f [file path]
오브젝트 스펙은 변경될 수 있으며 변경된 내용을 적용하기 위해서 apply 를 이용할 수 있는데
create 로 생성하고 apply 로 적용할 경우 일관성이 무너질 수 있으므로
apply 로 생성하고 apply로 변경된 데이터를 적용하는것이 좋다
kubectl apply -f [file path]
파드의 컨테이너 자동 복구
셀프 힐링 : 파드 자동 복구 기술
nginx 를 실행하고 있는 컨테이너 IP 에 1초마다 1개의 요청을 보내고 상태를 받는다
이 상태에서 nginx 를 실행하고 있는 컨테이너에서 kill -pid 로 프로세서를 죽이면
1초 상태
2초 상태
3초 상태
4초
5초
6초 상태
이처럼 4~5초에 요청에 대한 값을 못받다가 셀프 힐링이후 6초부터 연결되어 응답을 확인할 수 있다
현재 마스터 노드에는 run 생성 파드 1개, create 생성 파드 3개, apply 생성 파드 3개이며
run 으로 생성한 파드 1개, create or apply 로 생성한 파드 1개 총 2개의 파드를 삭제한다
총 7개에서 2개의 파드를 삭제하고 총 6개의 파드가 되었는데 이유는 run 으로 생성한 파드는
디플로이먼트에 속하지 않고 해당 파드를 관리하는 컨트롤러가 없다 그러므로 삭제 후 다시 생성되지 않는다
디플로이먼트에 속한 파드가 재생성되는 과정은 아래와 같다
감시 -> 차이 발견 -> 상태 변경 -> 변경 완료 후 감시
(감시)디플로이먼트의 레플리카셋이 파드를 감시하고 있으며
(차이 발견)파드가 삭제 되었음을 확인 한다
(상태 변경)replicas=6 에 맞도록 새로운 파드를 생성하여 개수를 맞춘다
(변경 완료 후 감시)다시 감시를 진행 한다
디플로이먼트에 속한 파드를 제거하고 싶은 경우 상위 디플로이먼트를 삭제해야 파드가 삭제된다
노드 자원 보호하기
노드는 쿠버네티스 스케줄러에서 파드를 할당받고 처리하는 역할을 하는데 특정 노드에서 문제가 발생시
파드에도 문제가 파생될 수 있다 이러한 케이스에서 사용하는 방법으로
cordon 을 사용하여 특정노드에 pod 가 생성되지 않도록 SchedulingDisabled 상태로 변경한다
kubectl cordon [node name], 해제 : kubectl uncordon [node name]
cordon 을 적용하고 scale 을 이용하여 replicas=3 -> 9 로 변경 시
해당 노드를 제외한 나머지 노드에만 파드를 생성한다
노드 유지보수
drain : 특정 노드안에 파드를 삭제하고 다른 노드에 생성 후 상태를 ScheduleDisabled 로 변경
kubectl drain [node name]
daemonset 무시하고 진행하는 방법, daemonset 에 대한 내용은 뒤에 나올 예정
kubectl drain [node name] --ignore-daemonsets
파드 업데이트 및 복구
--record 옵션 : 배포한 정보의 히스토리를 기록
kubectl apply -f [file path] --record
rollout history : record 옵션으로 기록한 히스토리 확인
kubectl rollout history deployment [deployment name]
rollout status : 상태 확인
kubectl rollout status deployment [deployment name]
apiVersion: apps/v1
kind: Deployment
metadata:
name: rollout-nginx
spec:
replicas: 3
selector :
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.12
nginx 컨테이너 버전 업데이트
kubectl set image deployment rollout-nginx nginx=nginx:1.16.0 --record
업데이트 실패 복구
undo : 명령을 취소하고 마지막 전 단계 상태로 복구
kubectl rollout undo deployment [deployment name]
--to-revision=1 옵션 : 특정 시점으로 되돌아 가고 싶은 경우
kubectl rollout undo deployment [deployment name] --to-revision=[history version number]
