반응형
리뷰 (Review)
더보기
Docker Network
- 가상 네트워크, Virtual Network Interface
- docker0 브리지에 연결하여 172.17.0.0/16 CIDR 범위로 IP 주소 할당
Docker Network Interface
- docker0
- Docker 설치 시 기본적으로 제공되는 가상 브리지 네트워크
- IP Address 172.17.0.1
- vethxxxxxx
- container 내부에 제공되는 network interface eth0와 한 쌍으로 제공
- docker0와 가상의 터널링 네트워크 제공
- eth0
- Docker container에 생성되는 기본 network interface
- docker0를 게이트웨이로 사용
- 순차적으로 IP Address를 할당받거나 사용자가 지정
Docker Network 종류
- Bridge network (default)
- 별도의 설정없이 사용했을 때 기본으로 사용하는 network로 host와 별도의 가상 네트워크 사용
- 포트 포워딩(docker run -p 옵션)으로 외부 network와 연결
- Host network
- container의 network 환경을 host의 network 환경과 동일하게 사용
- None network
- network를 사용하지 않고 local network (docker virtual network) 만 사용
Docker Network 명령
- docker network ls
- docker network create
- docker network rm <네트워크 이름>
- docker network inspect <네트워크 이름>
Docker Compose
- 공통성을 갖는 container application stack을 YAML 코드로 정의한 정의서
- 정의서를 실행하는 다중 container 실행 도구 (IaC 도구)
- 공통의 목적을 갖는 Application stack을 코드로 정의해서 한 번에 서비스를 올리고 관리할 수 있는 도구
- test, development, operation의 모든 환경에서 구성이 가능한 orchestartion 도구 중 하나
- 다양한 관리 기능을 가지고 있지 않기 때문에 test와 development 환경 구성에 적합
Kubernetes 개요
Application 배포 방법
- Traditional Deployment
- Application 구성
- Application Binary (bin)
- Application이 의존하는 Libarary (lib)
- Application을 배포받아 실행할 수 있는 여러 요소를 개별 computer에 배포
- Application 구성
- Virtualized Deployment
- Hypervisor 기반의 가상 머신을 통해 Application 생성 및 배포
- Container Deployment
- Application이 격리된 프로세스에서 동작할 수 있도록 image를 배포하는 방식
Application Architecture
- Application을 구성하는 방법
- Monolithic Architecture
- Application 전체가 하나의 운영체제 프로세스로 실행
- 하나의 객체로 개발, 배포, 관리
- 하나의 변경 사항을 적용하기 위해 전체를 다시 빌드 / 테스트 / 배포
- Application 확장이 어렵다.
- Microservice Architecture
- 각 micro service는 독립적인 프로세스로 실행되며 API (Application Programming Interface)로 또 다른 micro service와 통신
- 새로 추가되거나 변경 사항이 발생하면 해당 서비스만 빠르게 빌드 / 테스트 / 배포
- resource가 더 필요한 서비스만 별도로 확장 가능
- Microservice Architecture의 구성 요소는 독립적인 방식으로 개발
- 각각의 기능을 micro service 단위로 나누어서 개발 / 테스트 / 배포함으로써 구성 요소의 수가 증가하고
각각의 micro service 간의 종속성 관리가 어렵다는 단점이 있다.
- Application 개발 과정
- 개발
- 테스트
- 통합 → Monolithic Architecture
- 배포
- 유지 보수
- 개발, 프로덕션 환경에 대한 일관된 환경 구성
- 개발, 배포하는 구성 요소와 상관없이 개발자와 운영자가 해결해야 하는 문제는 Application 실행 환경이 매번 다른 환경이라는 점
- 위의 문제를 줄이기 위해서 프로덕션 환경에서는 Application 개발과 프로덕션이 정확히 동일한 환경에서 되도록 구성한다.
- 개발자와 운영자 간의 다른 생각
- 개발자 - 새로운 기능을 만들고 사용자 경험 향상에 중요도를 정한다.
- 운영자 - 개발자에게 우선순위가 낮은 시스템 보안, 사용률과 같은 측면에 중요도를 정한다.
Kubernetes 필요성
- 개발자는 기능 개발을 시스템 관리자(운영자)는 보안, 사용률과 같은 측면에 중요도를 부여
- Kubernetes를 사용하면?
- 개발자는 특정 인프라 관련 서비스를 Application에 구현하지 않아도 되고 실제 기능 개발에 집중
- 시스템 관리자(운영자)는 Kubernetes가 Application을 재배치하고 조합함으로써 리소스를 훨씬 효율적으로
관리할 수 있고 장애가 발생하더라도 자동으로 처리
- 마스터 노드
- 전체 Kubernetes 시스템을 제어하고 관리하는 Kubernetes control plane 실행
- 워커 노드
- 실제 배포되는 container application 실행
- 클러스터
- 마스터 노드와 워커 노드의 집합
Kubernetes 구성 요소
Kubernetes (k8s)
- Kubernetes는 container화 된 Application을 쉽게 배포 관리할 수 있는 orchestration 도구
- 구글이 내부적으로 사용하던 container 관리 도구를 오픈 소스화하여 공개한 container orchestration 도구
- 현재는 CNCF 재단에서 관리 및 운영
- 참고 자료
Kubernetes 구성 요소
- 마스터 노드 (Contol Plane)
- 클러스터 제어 - 워커 노드 관리
- kube-apiserver
- 사용자 상호 작용 수행
- Kubernetes 제어 명령 수신
- API 명령 수신
- kube-scheduler
- 새로운 Pod (container) 생성 감지
- 실행시킬 워커 노드 선택
- etcd
- 클러스터의 모든 데이터 보관
- 고가용성을 보장하는 Key-Value 저장소
- 어떤 노드가 존재하고 클러스터에 어떤 리소스가 있는지와 같은 정보 저장
- kube-controller-manager
- deployment 같은 리소스 컨트롤 관리
- API 서버를 통해 클러스터 공유 상태 감지
- 현재 상태를 원하는 상태로 이행하는 컨트롤 루프 관리
- cloud-contoroller-manager
- public cloud와 연동하여 로드 밸런서나 디스크 볼륨 같은 자원 관리
- 워커 노드
- 컨테이너화 된 Application 실행
- kubelet
- 각 노드에서 실행되는 에이전트
- container run-time을 관리하고 상태를 모니터링
- Pod에서 container가 확실하게 동작하도록 관리
- kube-proxy
- 각 노드에서 실행되는 네트워크 프록시
- Service 개념 구현부
- 서로 다른 노드에 있는 Pod 간 통신이나 POD와 인터넷 사이의 트래픽 라우팅
- container run-time
- container 제어 기능 (실행, 중지, 삭제 등) - Docker (기본적으로 많이 사용)
- CRI (Container Run-time Interface) - 공통 container run-time 규격
- Kubernetes를 사용하기 위한 기본 환경 구성은 클러스터 생성을 의미하고 클러스터는 여러 개의 클러스터를 생성할 수 있다.
Kubernetes 환경 구성
Kubernetes 환경 구성 요소
- Kubernetes 환경 구성 필수 요소
- CRI (Container Run-time Interface)
- Kubeadm
- Kubectl
- Kubelet
- CNI (Container Network Interface)
- 마스터 노드
- CRI (Container Run-time Interface)
- Kubeadm
- Kubectl
- Kubelet
- CNI (Container Network Interface)
- 워커 노드
- CRI (Container Run-time Interface)
- Kubeadm
- Kubectl
- Kubelet
Kubernetes 환경 구성 종류
- KubeAdm
- Kubernetes에서 제공하는 클러스터 생성 및 관리 도구
- KubeSpray
- Kubernetes 클러스터를 배포하는 오픈 소스 프로젝트
- 다양한 형식으로 Kubernetes 클러스터 구성 가능
- on-premise에서 상용 서비스 클러스터 운영 시 유용
- 다양한 CNI 제공
- MiniKube
- Local 시스템에 설치 가능
- 설치가 간단하면서 Kubernetes가 제공하는 기능 활용 가능
- 개발 도구와 MiniKube 연계 가능
- 단일 노드 (워커 노드) 형태로 동작
- 노드를 가상화 형태로 생성하기 때문에 Docker, VirtualBox 등의 가상화 도구가 추가로 필요하다.
- 학습 / 개발용
- k3s
- 경량 Kubernetes 배포판
- CNCF에서 육성하는 프로젝트이며 Rancher Labs에서 제작
- k3s 실행 파일을 통해 서버와 에이전트만 구동하면 Kubernetes 각 구성 요소가 간편하게 설치되고
Kubernetes 클러스터가 구성된다. - 마스터 노드의 etcd를 경량 파일형 DBMS sqlite를 사용한다.
- IoT, 학습용 초소형 컴퓨터 (라즈베리파이 등) 에도 사용 가능
- Docker Desktop
- Linux / Windows / MacOS에서 사용 가능
- Docker Desktop 설정에서 Kubernetes를 활성화하면 MiniKube와 유사하게 Kubernetes 사용 가능
- rancher
- Kubernetes 클러스터뿐만 아니라 운영에 필요한 모니터링, 보안 관련 기능을 쉽게 설치 가능
- rancher의 관리 도구를 사용해서 새로운 Kuberntes 클러스터를 쉽게 생성하고 여러 클러스터를 한 곳에서 관리
- 대규모 시스템 관리를 고려하여 많은 도구를 제공
CRI (Container Run-time Interface)
- Docker 기반 Kubernetes 구조
- Kubelet이 명령을 받으면 Dokcer runtime을 통해 container를 생성하거나 삭제하는 생명 주기 관리 구조
- Docker 이외 다양한 container 기술 적용 Kubernetes 구조
- Docker 이외 다양한 container 기술이 생기면서 Kubernetes에서 다양한 container runtime을 지원하게 되었고,
그때마다 Kubelet의 코드를 수정하는 문제 발생
- Docker 이외 다양한 container 기술이 생기면서 Kubernetes에서 다양한 container runtime을 지원하게 되었고,
- Kubelet 수정 없이 다양한 container 지원 Kubernetes 구조
- Kubelet 수정 없이 다양한 container runtime을 지원하기 위한 통일된 인터페이스 스펙이 CRI (Container Runtime Interface)
- container runtime이 CRI 스펙에 맞추어 구현되면 kubelet 수정 없이 새로운 container runtime을 plug-in 구조로
추가하여 사용할 수 있는 구조 제공
- OCI (Open Container Initiative)
- 새로운 container runtime이 생길 때마다 CRI를 수정하는 문제가 생기므로 container runtime을 표준화한 결과물
- OCI 스펙에 맞춰서 구현된 container runtime은 별도의 CRI 구현 없이 OCI 구현체의 관리가 가능
- OCI 스펙에 따른 container runtime을 관리하는 CRI component를 CRI-O라는 component로 구현
- OCI 스펙을 준수한다면 CRI-O를 통해서 kubelet으로부터 명령을 받을 수 있다.
- 참고 자료
- CRI-O
CNI (Container Network Interface)
- CNI는 CNCF 프로젝트
- CNI는 container 간의 네트워킹을 제어할 수 있는 plug-in 방식으로 만든 표준
- 다양한 형태의 container runtime과 orchestration 사이의 네트워크 계층을 구현하는 방식
- Kubernetes에서는 Pod (container) 간 통신을 위해서 CNI 사용
- CNI는 Calico, Weavenet, AWS CNI 등 다양한 종류가 있다.
KubeAdm을 이용한 Kubernetes 환경 구성
- Master node, Worker node에 해당하는 서버 생성 (준비) - Kubernetes 설치 가능 최소 사양 이상으로 구성
- 스왑의 비활성화, kubelet이 제대로 작동하게 하려면 반드시 스왑을 하지 않도록 설정한다.
- sudo swapoff -a : swap 기능 off
- echo 0 > /proc/sys/vm/swappiness : kerner 속성의 swap을 disable, root 사용자로 전환 후 수행
- sed -e '/swap/ s/^#*/#/' -i /etc/fstab - swap을 하는 파일 시스템을 찾아서 삭제
- 필수 port 번호 확인 후 포트 개방
- 스왑의 비활성화, kubelet이 제대로 작동하게 하려면 반드시 스왑을 하지 않도록 설정한다.
- Master node, Worker node에 container runtime 환경 구성 - Docker 설치 (40일차에 설치 순서 참고)
- kubeadm, kubectl, kubelet 설치
- kubeadm - 클러스터를 부트 스트랩 하는 명령
- kubectl - 클러스터와 통신하기 위한 CLI
- kubelet - 클러스터의 모든 머신에서 실행되는 Pod와 Container 시작과 같은 작업을 수행하는 component
- Master node / Worker node 구성
- CNI 구성
- Kubernetes 환경 구성 확인
TIF
주말 동안 결혼식 참석 때문에 금요일 밤부터 일요일까지 날려먹어서
구글 스터디잼 쿠버네티스 심화 과정 Production 2주차를 오늘 마무리했다.
실습은 크게 어렵지 않았다.
부하 생성기를 통해서 부하를 일으키고 이를 monitoring, logging 하는 기능들과
GKE에서 SQL 사용하는 것과 CI/CD 등을 실습을 통해 배울 수 있었다.
쿠버네티스 명령어까지 조금 더 배우고 했으면 좋았을 텐데 하는 아쉬움이 조금 남는다.
2022. 10. 06 에 작성된 글입니다.
반응형
'구름 쿠버네티스' 카테고리의 다른 글
구름 쿠버네티스 전문가 과정 6기 - 47일차 (3) | 2023.11.03 |
---|---|
구름 쿠버네티스 전문가 과정 6기 - 46일차 (3) | 2023.11.02 |
구름 쿠버네티스 전문가 과정 6기 - 44일차 (1) | 2023.10.30 |
구름 쿠버네티스 전문가 과정 6기 - 43일차 (3) | 2023.10.27 |
구름 쿠버네티스 전문가 과정 6기 - 42일차 (2) | 2023.10.26 |