Linux Container 기술을 적용한 도커엔진으로 도커 Hub Registry를 통한 Docker Image를 관리한다.
어디서나 이미지를 빌드하여 쉽게 배포/운영 할 수 있게 하는것이 목표이다.
컨테이너 오케스트레이션
컨테이너 호스트 여러개를 관리하는 방법으로
스케줄링
클러스터 관리
서비스 디스커버리
모니터링
이 있다.
쿠버네티스
컨테이너 오케스트레이터로 google borg에서 시작되어 오픈소스화 되었다. ( go언어로 작성 )
장점
Automatic binpacking : 가용성의 희생없이 리소스 사용과 제약사항을 기준으로 자동으로 컨테이너 를 스케줄링.
self-healing : 자동으로 문제가 발생한 노드의 컨테이너를 해제
horizontal scaling : CPU와 메모리 같은 리소스 사용에 따라 자동으로 애플리케이션을 확장. 경우에 따라 사용자 정의 측정값을 기준으로 한 동적인 확장 가능.
service discovery and Load balancing
caontainer에 고유 IP 부여 : 여러개의 container를 묶어 단일 service로 부여하는 경우 단일 dns name으로 접근하도록 로드 밸런싱을 제공
Automatic rollouts and rollbacks
다운 타임 없이 애플리케이션의 버전별 롤백, 롤아웃 가능.
Secret and configuration management
애플리케이션의 secret과 configuration 정보를 이미지와 독립적으로 구분하여 별도의 이미지 재생성 없이 관리
Storage Orchestration
Batch execution CI워크로드와 같은 batch성 작업지원, crontab 형식으로 스케줄링 가능
쿠버네티스 마스터 : API server. Controller Manager Server. Scheduler Server : 팀장 역할. 워크로드를 워크노드에 할당 등..
Kube - apiserver : cluster와 상호작용을 위한 k8s 서버.
Kube - scheduler : worker node에 있는 pod를 스케줄링
Kube - Controller - manager: Deploymenents 나 Replication controller 등 관리
Kube - cloud -manager : public cloud provider관리.
etcd : master cluster에서 k8s object 저장소로 사용
쿠버네티스 노드
Container runtime : 컨테이너 실행을 위한 Docker engine 포함
kubelet : master 명령 수행 에이전트
kube-proxy : 워커가 받은 트래픽에 대한 네트워크 프록시. 어떤 pods에 전달? (외부요청을 받아)
→ 인터넷을 통해 들어오는 요청을 Ingress controller를 거쳐 kube-proxy로
CAdvisor : 리소스 사용 / 성능 통계 제공 나바쁘다 . 한가하다.
Kubernetes Object Model
k8s object에 대한 manifest를 YAML형식으로 작성. Master 노드의 API Server를 통해 클러스터에 k8s Object 생성
k8s object API Version
Alpha → Beta → stable
Basic Objects
pod -중요
service -중요
volume
namespace
controllers
ReplicaSet
ReplicationController
Deployment -중요
StatefulSets
DaemonSet
Garbage Collection
Jobs
CronJob
Pod ( 내부에선 마치 서버처럼 이용 )
worker 노드에서 실행되는 컨테이너의 집합 ( 보통 1개의 컨테이너 )
하나의 Pod에는 한개 이상의 서비스로 지정 될 수 있다.
각각의 pod 에는 고유한 IP가 할당된다 (내부 IP)
하나의 pod 내에서는 PID namespace, network와 hostname 공유
Service ( 외부에 노출시킬 때)
Label selector로 선택하여 하나의 endpoint로 노출되는 pod의 집합
Type : cluster IP, Node Port, Load Balancer, Exteral Name
ExternalTrafficPolicy
service.spec.externalTrafficPolicy-이 서비스가 외부 트래픽을 노드 로컬 또는 클러스터 전체 엔드 포인트로 라우팅 하려는지 여부를 나타냅니다. 사용 가능한 옵션에는 클러스터 (기본값)와 로컬의 두 가지가 있습니다. 클러스터는 클라이언트 소스 IP를 모호하게하고 다른 노드로 두 번째 홉을 유발할 수 있지만 전체적인로드 확산이 좋아야합니다. Local은 클라이언트 소스 IP를 보존하고 LoadBalancer 및 NodePort 유형 서비스에 대한 두 번째 홉을 피하지만 잠재적으로 불균형 트래픽 확산 위험이 있습니다.
Cluster정책: 트래픽이 클러스터의 정상 GKE 노드로 부하 분산된 다음 kube-proxy가 트래픽을 pod가 있는 노드로 전송합니다.
Local정책: 백엔드 pod 중 하나가 없는 노드는 TCP/UDP 부하 분산기에 비정상으로 표시됩니다. 트래픽은 pod가 있는 나머지 정상 클러스터 노드 중 하나로만 전송됩니다. 트래픽은 kube-proxy에 의해 다시 라우팅되지 않고 대신 IP 헤더 정보가 그대로 있는 로컬 pod로 직접 전송됩니다.
컨테이너에서 읽혀지거나 사용되는 소량의 민감한 정보. 특수한 Volume이 자동으로 연결되어 container에서 사용 가능. 수동으로 Secret을 생성하고 연결하여 사용가능. Base64로 encoding 될 뿐 암호화 x, volume으로 연결된 file형식 또는 변수 형식으로 사용가능
Deployment Controller
pod 의 배포 및 관리에 사용
ReplicaSet을 자동으로 생성 ( 같은 기능을 하는 단위로 버전 집합 )
pod에 대한 rolling 업데이트 관리
ReplicaSet ( 같은 기능을 하는 pod의 집합 )
Replication Controller의 새로운 버전
가용성과 확장성 보장
사용자의 요청에 따른 pod의 숫자를 유지하고 관리
각각의 pod가 필요로하는 정보 명세가 있는 template을 이용
StatefulSet
Deployment와 유사하나 pod별 고정된 identity(name, network Id등) 할당
DaemonSet
모든 Node에 배포되어 실행(Node Selector로 정의하는 경우 일부 Node에서만 실행)
