Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à [넥슨] kubernetes 소개 (2018)
Similaire à [넥슨] kubernetes 소개 (2018) (20)
Plus de 용호 최
Plus de 용호 최 (20)
[넥슨] kubernetes 소개 (2018)
- 2. 쿠버네티스의 등장 • 사용자들은 무정지 배포를 원함 • 수시로 배포가 가능해야함 • 컨테이너화가 되어야 빠르게 다운타임 없이 배포가 가능해짐 • 쿠버네티스는 프로덕션에도 충분히 사용 가능
- 3. 쿠버네티스란? ● 어플리케이션을 배포하고 확장 및 관리를 자동화 ● 컨테이너 오케스트레이션 ● 구글에서 관리하는 대규모 오픈 소스 프로젝트 ● 주요 클라우드 공급자인 AWS, GCP, Azure 에서 쿠버네티스를 기반으로 한 서비스 제공 ● 마이크로 서비스에 이상적 ○ 가상 머신을 사용하여 마이크로 서비스를 배포할 때처럼 많은 오버헤드가 발생하지 않음
- 4. 컨테이너 오케스트레이션이란? ● 컨테이너 배포 관리를 의미 ○ 여러 컨테이너를 배포하고 관리하는 프로세스를 최적화 하는 것이 목적 ● 오케스트레이션 기능 ○ 프로비저닝 : 필요시 시스템을 즉시 사용할 수 있도록 시스템 자원을 미리 할당, 배치, 배포 상태로 준비해두는 것 (여기서는 컨테이너를 통해 이를 수행) ○ 구성 스크립트 : 특정 어플리케이션 구성 정보를 컨테이너에 로드 ○ 모니터링 : 컨테이너 상태를 감시하고 로드밸런싱, 장애탐지, 오토스케일링 ○ 서비스 탐색 : 컨테이너가 적합한 자원을 찾기 위해 서비스 탐색을 사용하고 외부로 노출 ● 대표적으로 도커 스웜, 쿠버네티스, 아파치 메소스가 존재
- 5. 쿠버네티스 클러스터 • 쿠버네티스가 시스템을 구성하는 다양한 업무를 실행하는데 사용 • 다수의 호스트 저장소와 네트워킹 자원의 집합 • 노드와 마스터를 아우르는 개념 • 최소 3개의 노드 사용 권장 • 도커 이미지를 배포할 수 있는 클러스터 • 쿠버네티스는 호스트들이 의존적이지 않는 구조로 구성 • 의존적이지 않기 때문에 클러스터의 어떤 호스트로든 배포가 되어도 상관 없음
- 7. 마스터 • 클러스터를 관리 • 마스터의 구성 • API 서버 • 스케줄러 • 컨트롤 관리자 • 등등 • 마스터의 역할 • Pod 스케줄링 및 이벤트 처리 • 어플리케이션 실행 및 중지 • 어플리케이션 스케일링 • 어플리케이션 업데이트
- 8. 노드 • 단일 호스트를 의미 • 물리 머신이 될 수도 있고 가상 머신이 될 수도 있음 • Pod를 실행 • kubelet과 kube proxy등 여러 쿠버네티스 컴포넌트를 실행 • 노드는 일반적으로 일하는 노드(과거의 미니온)와 마스터 노드로 구분
- 9. 노드가 수행하는 것 • Kubelet • 쿠버네티스 마스터와 노드 간의 통신을 담당 • 머신에서 동작하는 컨테이너들과 Pod들을 관리 • 마스터 밑의 하위 관리자 같은 느낌 • 컨테이너 런타임 (Docker Container) • 실제 일하는 녀석들 • 마스터 = 본부장님, Kubelet은 팀장님, 컨테이너 런타임은 사원
- 10. 미니큐브 (Minikube) • 경량화된 쿠버네티스 • 로컬에서만 사용가능 • 하나의 VM 생성 • 하나의 노드만 사용가능 • Linux/Mac/Windows 지원 • 테스트용으로 좋음
- 12. 쿠버네티스 배포 • 배포 설정을 만들어야함 • 배포 설정에는 컨테이너를 어떻게 만들고 업데이트를 수행할지에 대해 정의 • 어플리케이션 인스턴스가 만들어지면 쿠버네티스 Depolyment Controller는 이 인스턴스를 지속적으로 모니터링 • 노드가 다운되거나 삭제되면 다른 노드에 배포함으로써 유지 • 자동화
- 13. Kubectl • Kubectl을 사용해서 Deployment를 만들고 관리 • Kubectl은 쿠버네티스 API를 사용해서 클러스터와 상호작용 • 마스터와 소통 • Deploy 생성 시 필요 사항 • 컨테이너 이미지명 • 몇 개의 어플리케이션을 만들지 • 스케일은 어떻게 할지 • 업데이트는 어떻게 할지
- 15. Pod ● 쿠버네티스의 작업 단위 ● 한개 또는 여러 개의 컨테이너를 포함 ● 같은 노드에 포함된 포드들은 함께 스케줄링 ● Pod 단위로 IP 주소가 할당되고 포트 공간이 동일 ● 필요에 따라 버리고 교체할 수 있으며 짧은 수명을 가지는 일시적인 요소 ● 각 Pod는 고유한 ID를 가지고 있으므로 필요시 분별 가능
- 16. Node 내 Pod 구성
- 17. 노드가 죽으면? • 워커 노드가 죽으면 그 안에서 동작하는 Pod들도 함께 죽음 • 외부에서는 Pod가 제거되었는지 새로 생성되었는지 모르는 상태로 정상적인 서비스를 제공받아야함 • ReplicationController는 이를 감지하여 어플리케이션을 유지하기 위해 다른 노드에 Pod들을 생성하여 복구
- 18. Kubectl을 통한 트러블슈팅 • Kubectl get : 리소스 리스트 • Kubectl describe : 리소스에 대한 자세한 정보 • Kubectl logs : pod안의 컨테이너로부터의 로그 출력 • Kubectl exec : pod 안의 컨테이너에 명령 실행
- 20. 서비스 ● 사용자가 외부 자원이나 가상 IP를 통해 서비스에 접근 가능 ● OSI 7계층의 3계층(TCP/UDP)에서 동작 ● 서비스에 속한 Pod들은 LabelSelect로 판단됨 ● 지금까지의 Pod, Node로는 외부에서의 접속이 불가능 ● Proxy를 통해서만 접근 가능 ● 서비스를 사용해서 쿠버네티스 클러스터 외부로 어플리케이션을 노출 ● 로드밸런싱 및 서비스 디스커버리 수행
- 21. 라벨 (label) ● key-value 쌍의 객체 집합이며 객체의 식별에 사용 ● Pod를 그룹화할 때 사용 ● 복제 컨트롤러(Replication Controller), 복제 집합(Replica set), 동적 객체 그룹에서 동작 ● 라벨 설계의 제한 사항 ○ 반드시 고유한 키를 가져야함 ○ 접두사와 이름 두 부분으로 구성 ■ 접두사는 선택사항 ■ 접두사는 슬래시로 이름과 구분 ■ 이름은 필수사항
- 22. 라벨 셀렉터 ● 라벨을 기반으로 객체를 선택 ● 동일한 라벨이 부여된 객체들을 연산자를 통해 일괄 선택 가능 ○ ex) 라벨 키가 role이고 값이 webserver인 객체 선택 ■ role = webserver ● = 또는 ==, != 을 통해 라벨에 따른 객체 선택 ■ 복수의 조건은 쉼표로 구분 ● role = webserver, application != foo ■ 집합은 다양한 값을 기반으로 객체 선택 ● role in (webserver, backend)
- 23. 서비스와 라벨
- 24. 서비스와 라벨
- 25. 서비스에서 IP 노출 방법 ● ClusterIP : 클러스터 내부에서만 접근 가능 ● NodePort : NAT를 사용하여 각 노드의 Port를 오픈 ● LoadBalancer : External 로드밸런서를 만들어서 고정된 외부 IP 배정 ● ExternalName : DNS 기능을 통해 도메인명(CNAME)으로 외부에서 접근
- 26. 복제 컨트롤러와 복제 집합 ● 라벨 셀렉터로 식별된 Pod 그룹을 관리하고, 특정 수만큼 실행 중인지 항상 확인 ● 복제 컨트롤러는 이름의 동일 여부로 구성원을 확인 ● 복제 집합은 집합 기반 선택을 사용 ● 지정한 수의 Pod가 항상 실행되도록 보장 ○ 문제가 발생하여 Pod가 일정 수준 이하로 내려가면 쿠버네티스는 새로운 인스턴스를 시작
- 28. 스케일링 ● kubectl을 사용해서 스케일링 ● 트래픽이 증가하면 자동으로 스케일 아웃 수행 ● 마스터가 알아서 노드에 Pod 확장 및 축소
- 30. 롤링 업데이트 • Kubectl을 사용해서 수행 • 무정지 배포 • 점진적으로 Pod를 하나씩 업데이트
- 36. 감사합니다.