개발 배경
• Container는 stateless, immutable, mortal (상태를 가지고 있지 않고, 변화하지 않으며, 언제든 죽을 수 있는)개념을 기반으로 아키텍처를 구성하다 보면 운영에 앞서 반드시 필요한 것이 Container Orchestration(=Kubernetes)이다
• Container Orchestration은 다수의 Container를 다수의 호스트(클러스터)에 적절하게 분산 실행하고, 원하는 상태(desired state)로 실행상태를 유지해 주고, 다운타임 없이 유동적으로 스케일을 확장/축소할 수 있게 도와준다
• 사용자가 Container에 대한 동작과 다른 Container와의 관계를 정의하면 배포/운영/스케일링에 문제가 없도록 자동으로 관리되는 운영 시스템이라고 할 수 있겠다.
오케스트레이션 프레임워크의 종류
특징
Automatic binpacking
• 가용성을 희생하지 않는 범위안에서 물리적 리소스를 충분히 활용해서 Pod을 (자동) 배치한다
• binpacking이란 컨테이너가 호스트의 물리적 리소스를 충분히 활용할 수 있도록 효율적으로 고르게 배치해서 불필요한 물리적 리소스의 낭비를 줄이는 것을 의미한다. (Pack in a Camping Bin)
Self-healing
• Container의 실행 실패, Node(K8s에서 Pod을 실행하는 Slave Host)가 죽거나 반응이 없는 경우, health check에 실패한 경우에 해당 Container를 자동으로 복구한다
• Kubernetes가 관리하는 가장 작은 배포단위인 Pod은 언젠가는 반드시 죽는(mortal) 것으로 정의되어 있으며 Container, Node의 장애 상황발생 시에도 운영자가 기대하는 상태로 서비스가 무사히 실행될 수 있도록 Self-healing을 지원한다.
Horizontal scaling
• Pod의 CPU 사용량 혹은 app이 제공하는 metric을 기반으로 ReplicaSet (동일한 Pod을 몇 개 띄울지 정의) 을 scaling할 수 있다.
Service discovery and load balancing
• 익숙하지 않는 Service Discovery 매커니즘을 위해 Application을 수정할 필요가 없다 • K8s는 내부적으로 Pod에 고유 IP, 단일 DNS를 제공하고 이를 이용해 load balancing 한다
Automated rollouts and rollbacks
• application, configuration의 변경이 있을 경우 전체 인스턴스의 중단이 아닌 점진적으로 Container에 적용(rolling update) 가능하다
• Release revision이 관리되고 새로운 버전의 배포시점에 문제가 발생할 경우 자동으로 이전의 상태로 Rollback을 진행할 수 있다
Secret and configuration management
• Secret key, Configuration을 관리하기 위해 Secret, ConfigMaps Object가 제공되기 때문에 이미지의 변경없이 키/설정을 업데이트할 수 있고, 이를 외부에 노출(expose)하지 않고 관리/사용할 수 있다
• Secret은 데이터를 binary 형태로, ConfigMap은 text 형태로 저장한다.
Storage orchestration
• local storage를 비롯해서 Public Cloud(GCP, AWS), Network storage등을 구미에 맞게 자동 mount할 수 있다
설치 방식
All-in-One 방식
• Master와 Node가 동일한 Host에서 실행
• 기본적인 작동 방식을 이해하는데 도움
• 실제 환경에서는 사용하지 않음
Cluster 방식
• 1개의 Master와 2개 이상의 Node로 구성
• 필요할 때마다 Node를 추가해서 용량을 늘려 나감
• 실제 환경에서 주로 사용
Kubernetes 구성 방법
• Kubernetes 설치를 위한 VM 및 Physical Machine 필요
• Cloud 사업자(Google, Azure, AWS)가 제공하는 Kubernetes 사용
CentOS에 Kubernetes 설치하기
모델
ModaXtrem으로 master에 ssh 연결
설치전 기본 설정
modprobe br_netfilter
echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables
vi /etc/yum.repos.d/kubernetes.repo
cd /etc/yum.repos.d (##중요)
wget http://down.cloudshell.kr/k8s/kubernetes.repo
yum repolist -y
여기까지 해주고
docker 설치
docker 설치후 systemctl로 실행한다
후에 kubernetes 패키지 설치
systemctl start kubelet
systemctl enable kubelet
(Mater)
kubeadm init
Master의 경우 아래와 같이 설정해준다
docker node ls
kubectl get namespaes
kubectl get pods --all namespaces
• cluster 상태가 Not Ready이고 coredns 상태가 Pending이다. 이렇게 되면 각 Node들에서 실행중인 Pod들간에 통신이 안된다
• Pod Network를 생성하여 이 문제를 해결할 수 있다
• POD network는 node간에 통신을 하게 하는 overlay network이다
kubectl get pods -n kube-system
Pod Network 구성하기
export kubever=$(kubectl version | base64 | tr -d '\n')
weave-net 설치 : kubectl apply -f "cloud.weave.works/k8s/net?k8s-version=$kubever"
Nginx Pod을 Kubernetes cluster에 배포하기(Master에서 작업)
kubernetes 환경에서 실행중인 Pod은 한 개 이상의 container로 구성되어 있으며, 그 Pod에 있는 docker container들은 storage와 Network을 공유한다
kubectl create deployment mynginx --image=nginx
kubectl get deployments -o wide
kubectl get nodes
kubectl create service nodeport mynginx --tcp=80:80
kubectl describe deployment mynginx
kubectl get service
접속할 IP와 Port 번호 확인하기
kubectl get pods -o wide
kubectl get svc -o wide
namespace 단위로 cluster의 구성 내용 확인하기
kubectl -n kube-system get cm
-> kube-system이라는 namespace의 configmaps 확인하기
configmaps들의 각각의 상세한 내용을 꼭 확인해볼 것
kubectl get cm -n kube-system coredns -o yaml
kubectl get cm -n kube-system weave-net -o yaml
kubectl get cm -n kube-system kube-proxy -o yaml
kubectl 구문 • kubectl [command] [TYPE] [NAME] [flags] -o • command: run, create, apply, get, describe, delete • TYPE: pods, nodes, deployments, services, replicasets, configmaps 등등 • NAME: resource 이름(대/소문자 구분하므로 정확하게 입력해야 한다) • kubectl get pod example-pod1 example-pod2 • kubectl get pod/example-pod1 rc/example-rc1 • flags (=options) • 위치에 구애 받지 않는다 • kubectl -n kube-system get pod (=kubectl get pod -n kube-system) • -i, -t, -n, --all, --server, -f, --image, --replicas, --port • -o • -o wide/yaml/json • kubectl get 구문의 제일 마지막에만 사용한다 • 현 상태를 표시하는 형식이기 때문이다