공부 방식
- 쿠버네티스 환경 구성
- 배포를 통한 쿠버네티스 체험
- 쿠버네티스 인사이드
- 문제를 통해 배우는 쿠버네티스
- 쿠버네티스 오브젝트
- 쿠버네티스 Tips
강의 특징
1. 코드를 몰라도 들을 수 있음
2. 쿠버네티스의 전반적인 흐름을 이해할 수 있음
3. 나만의 쿠버네티스 테스트 환경을 가질 수 있음
4. 쿠버네티스 다루기를 시작할 수 있게 함
쿠버네티스가 하는 일
컨테이너를 관리
쿠버네티스란?
컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 오픈 소스 시스템, 컨테이너 오케스트레이션 도구
오케스트레이션 : 전체적인것을 아우러서 관리한다.
컨테이너화된 애플리케이션의 자동화 및 최적화
컨테이너 오케스트레이션의 목적
여러 컨테이너의 배포 프로세스를 최적화
도커(Docker)란?
쿠버네티스는 누가 만들었고 관리하나?
구글의 Borg 라는 시스템
성공한 오픈 소스 프로젝트
대표적으로 리눅스이다.
쿠버네티스 배포 종류
관리형 쿠버네티스
설치형 쿠버네티스(패키지)
구성형 쿠버네티스: 자유롭게 구성하는 요구사항, 교육 목적
웹에서 제공하는 쿠버네티스 환경
- 플레이 쿠버네티스: 4시간 시간제한 있음
- 쿠버네티스 플레이그라운드: 노드가 제한적임(자유로운 사용 보장x)
코드 설치
VAGRANT => 버추얼박스 에 코드를 보냄 => 가상 머신각각의 노드가 올라옴
어떤환경에서든 인터넷만 연결되면 사용할 수 있음
마스터 노드에서 워커노드에게 애플리케이션을 배포를 할꺼야라고 말을 해줌.
Pod란?
컨테이너의 집합
pod 생성
run nginx 이름, --image=nginx 사용하려는 이미지
파드 생성 완료
배포한 Pod IP 확인
kubectl get pod -o wide
현재 쿠버네티스 상태
쿠버네티스 클러스터: centOS 를 위해 쿠버네티스를 구성하는 4개를 묶어 클러스터라함
이런식으로 되어있는데 밖으로 나가는법
1. 문을 날리는 방법(보안 문제 생김)
2. 서비스라는 공간이 있음
밖으로 나가려면 문밖에 안전한 공간을 svc(service)라 함
배포한 pod를 연결을 하면 service를 통해 pod를 찾아가기 때문에 안전하게 동작함.
실제 구조
노드 포트를 통해 노드에 접속
파드에 직접 연결되는 구조는 아님
서비스를 통해 외부에 연결되는 파드 실습
kubectl expose pod nginx --type=NodePort -- port=80
파드를 노출
kubectl get service
service를 확인
INTERNAL-IP dp Port번호 넣어서 외부에서 확인
파드를 여러 개 사용하려면?
이전에는 파드를 한개만 배포하였음, 원하는 것은 1개 그 이상 배포를 할 수 있는 상태를 원함 => 디플로이먼트
디플로이먼트 배포방법
kubectl run : pod만 배포가능
kubectrl create: pod와 deploy 배포
kubectl apply: pod와 deploy 배포 파일이 필요함
배포 실습
create deployment deploy-nginx --image=nginx
get pods -o wide
deployment create로 pod를 배포할 때 명령어를 통해 배포
파일을 통해서는 한번에 여러개 배포가능
replicas 수가 배포수
pod의 배포수 늘리기
배포수 늘리는 명령
kubectl scale deployment deploy-nginx --replicas=3
파드를 한계를 극복하는 디플로이먼트
디플로이먼트를 노출하려면?
kubectl expose deployment deploy-nginx --type=NodePort --port=80 명령어 입력
kubectl get services 명령어 입력하면 디플로이먼트 포트번호가 나옴
성공
디플로이먼트를 노드포트로 노출
노드포트로 노출하는 것은 좋지 않음
가장 좋은 방법은 로드밸런서 타입으로 선언하는 것이 좋음
MetalLB를 이용해 로드밸런서 타입으로 선언함.
노드포트보다 로드밸런서가 좋은 점
노드포트: 노드 ip를 알려줘야함
로드밸런서: 고유의 ip를 만들어 알려줌
로드밸런서를 사용하면 가야 할 경로를 최적화해줌
이제 chk-hn이라는 새로운 디플로이먼트를 배포하겠음.
컨테이너를 모아 놓은 것은? pod
파드를 모아 놓은 것은? deployment(replicas로 갯수 변경)
쿠버네티스에서 서비스란? 문과 같은 역할 (노드포트, 로드밸런서)
배포한 것 삭제
kubectl delete service chk-hn
kubelctl delete service deploy-nginx
등등
파일 삭제
kubectl delete -f ~/
쿠버네티스는 어떻게 구성되어 있을까?
위의 것들로 쿠버네티스가 이루어져있음
구역을 나누는 네임스페이스(Namespace)
서로의 구역이 나누어져 있음
파드 배포 시에 쿠버네티스 구성 요소들이 하는 일
쿠버네티스의 기본 철학
마이크로서비스 아키텍처 하늘 일들이 모두 분업되어 있음(각자 일을 열심히 한다)
반대개념
모놀로식 아키텍처(밀집되어 다 한다)
쿠버네티스는 마이크로서비스 아키텍처 가 철학(각자의 일을 알아서 한다)
파드가 배포되면?
사용자가 kubectl create pod(s)명령을 내림 =>
API서버 & etcd 로 넘어가게됨 =>
선언적인 시스템
상태변경, 감시, 차이발견
API서버 , etcd
가지고 있는 현재 상태를 가지고 있는데, 정보를 etcd에 저장
기억할 것
선언적인 구조이며, 쿠버네티스의 각 요소들은 자기 할 일만 한다.
각자의 역할에 맞게 계속 그 일 만 하면서 업데이트
현재 쿠버네티스의 파드 배포 흐름
API서버는 모든 것의 중심에 있음
모든 것의 게이트웨이고 모든 것의 집합체이고 시작이자 끝이다 API는 굉장히 중요함
배포된 파드에 생기는 문제
파드를 실수로 지웠을 때
파드만 배포된 경우 문제가 생김
디플로이먼트 형태로 배포된 파드 디플로이먼트는 파드를 유지하기 때문에 문제가 생기지 않음
파드는 업데이트, 노드에 있는 파드를 옮길 때 파드를 지우고 다시 생성함
파드 삭제 실습
파드는 삭제하면 바로 날아감
deployment를 지우면 3개를 유지해야한다는 것을 규정되어있기 때문에 바로 생성을 함
쿠버네티스 구성 요소에 문제가 생기면?
대부분 바로 복구가 되지만
kubelet에 문제가 생기면 바로 복구가 되지 않음
그래서 배포가 제대로 이루어지지 않음
컨테이너 런타임
컨테이너 런타임에 문제가 생기면 더이상 파드를 배포할 수 없음
마스터노드에 문제가 생기면?
스케줄러가 삭제된다면?
마스터노드에 있는 중요한 요소들은 파드라 해도 문제가 생기면 바로 다시 만들어줌
스케줄러 말고도 마스터노드에 있는 파드는 삭제해도 다시 생성됨
마스터 노드에 kubelet을 맘추면?
쿠버네티스 오브젝트?
상태를 가지고있는 것
오브젝트는 추구하는 상태를 기술해 둔 것
볼륨
영속적인 데이터를 보존하기 위해 사용
pod는 언제든 상황에 따라 삭제되고 생성이 됨
pod가 이곳 저곳 돌아다니면 저장이 안되기 때문에 볼륨을 붙임
dpy-chk-log
업그레이드 순서
예약 단축어
yaml
pwd 현재 위치
touch test.yaml 현재 위치에 yaml 파일 생성
ls-al 현재 위치 파일 보기
vi test.yaml 파일 안에 코드 생성
kubectl apply -f test.yaml 파일 열기
kubectl get all -n metallb-system
