- kubectl get pod -o wide --watch - watch kubectl get pod -o wide
Job
: 배치 처리에 적합한 Controller로서 Pod의 성공적인 완료를 보장
: Job을 사용하여 Pod를 실행하면?
Pod의 작업이 정상적 종료 → 완료
Pod의 작업이 비정상적 종료 → 다시 실행시켜 Application의 작업을 하도록 함
전제 : Kubernetes에서 Pod은 항상 Running
실습) Job - wget http://down.cloudshell.kr/k8s/lab/job/job-exam1.yaml - watch kubectl get pod -o wide - kubectl apply -f job-exam1.yaml 60초 동안 sleep 프로세스 진행 중
60초 이내에 pod 종료(비정상적 종료) - kubectl delete pod pod_name 이렇게 하면 다시 생성한다
- kubectl apply -f replicationcontroller.yaml yaml
- kubectl get rc,pod -o wide - kubectl delete pod nginx-g5wrg → 특정 pod 삭제 시 새로운 pod 생성됨 - kubectl run myhttp --image=httpd --labels="app=nginx" --port 80 - kubectl get rc,pod -o wide --show-labels 새로 만들어진 pod는 알아서 종료된다.
- kubectl edit rc nginx → pod의 이미지, 갯수 등 다시 설정할 수 있다.
- kubectl delete rc nginx → Replication Controller 삭제 시 Pod도 삭제됨!! - kubectl delete rc nginx --cascade=orphan → Replication Controller만 삭제되고 Pod는 그대로 유지
ReplicaSet
: Replication Controller와 동일한 역할
차이점은 Replicaion Controller보다 더 많은 selector를 가진다는 점이다.
: Deployment를 생성하면 자동으로 ReplicaSet과 Pod이 생성됨 (Deployment를 삭제하면 자동으로 전부 삭제됨)
: Pod의 Rolling Update 및 Rolling Back 을 위해 주로 사용
실습) Rolling Update - wget http://down.cloudshell.kr/k8s/lab/deployment/deployment-v1.yaml - kubectl apply -f deployment-v1.yaml --record(--record: 업데이트 과정을 history로 기록) - kubectl rollout history deployment app-deploy deployment의 history를 볼 수 있다. - kubectl set image deploy app-deploy myweb-con1=nginx:1.15 --record - kubectl get pod → pod가 하나씩 순서대로 Update 된다 - kubectl describe pod (pod명) 이미지 업데이트 적용 - kubectl set image deploy app-deploy myweb-con1=nginx:1.16 --record - kubectl set image deploy app-deploy myweb-con1=nginx:1.17 --record
- kubectl rollout history deployment app-deploy history 확인 - kubectl rollout undo deploy app-deploy undo 결과 - kubectl rollout undo deploy app-deploy --to-revision=2 → 특정 단계로 돌아간다
: 상태를 유지하는 항목 ▶ Pod 이름을 순서대로 명명(0~N), Pod의 Volume(PVC 이름), Network (Headless Service)
※ 주의 ※ StatefulSet 생성 시 yaml 파일에는 serviceName, replicas, podManagementPolicy, terminationGracePeriodSeconds이 반드시 포함되어야 한다
yaml 일부
- kubectl apply -f statefulset.yaml
StatefulSet으로 Pod이 생성된 경우에는 Pod이 삭제되면 이전의 삭제된 Pod의 이름과 동일한 Pod이 생성된다.
실습) StatefulSet의 rollingUpdate.partition 수정하기 : StatefulSet에 변경사항이 있을 때 rollingUpdate.partition에서 지정한 값보다 작은번호의 Pod은 변경되지 않고 크거나 같은 번호만 변경시킨다 : 서버 패치할 때 등의 경우에 사용한다
- kubectl apply -f statefulset.yaml (## web-0, web-1, web-2가 실행되고 있음) - kubectl edit statefulset web image를 nginx에서 nginx:1.14로 변경partition 부분을 0에서 2로 변경
- kubectl get statefulsets.apps
2보다 작은 0과 1은 계속 동작하고 2만 수정된다.
Deployment, DaemonSet, StatefulSet의 공통점과 차이점
ⓐ 공통점
Rolling update 및 Rollback 가능
각각을 삭제하면 Pod도 동시에 삭제됨
ⓑ 차이점
Deployment - Pod이 어떤 Node에 생성될 지 예측 불가
DaemonSet - Node별로 동일한 Pod이 하나씩 생성
StatefulSet - serviceName 필요 - Pod 이름 및 볼륨 유지 - partition 값에 따라 업데이트 되지 않을 Pod을 지정할 수 있음
동일한 서비스를 제공하는 여러 개의 Pod에 접근할 수 있는 하나의 IP를 제공 (Service 자신이 갖고 있는 Selector 값과 Cluster에서 운영중인 Pod의 Label 값이 동일한 Pod으로 연결된다. Service는 자신의 EndPoint에 Pod를 추가시켜 관리한다.)
추가) kubectl run으로 pod 생성 후, Service도 생성했는데 오류가 나는 경우
→ pod의 labels 값과 service의 selector 값을 비교해볼 필요가 있다.
※ Pod의 Labels 값 확인
- kubectl get pod -o wide --show-labels
※ Service 내부 설정 정보 확인
- kubectl edit service 서비스명
Service는 Pod에 연결시켜주는 Network
어느 Service 유형이든 결국 Cluster IP를 통해 Pod에 접근 (Pod는 기본적으로 한 Node에서만 실행되지 않고 상황에 따라 Cluster내에 속한 여러 Node로 옮겨다닌다. 그러므로 Pod의 IP로 접속하는 데는 한계가 있고 동일한 서비스의 대표 IP인 Service의 IP로 접근하는 것이 편리하다.)
Service 종류
1. ClusterIP
: Default Service로서 Pod들이 클러스터 내부의 다른 리소스들과 통신할 수 있도록 해주는가상의 클러스터 전용 IP
(IP는 Container에는 없고 Pod 에만 있다. Pod IP는 변경이 가능하므로 변경되지 않는 Virtual IP를 갖는 Service를 사용해야 한다)
: Cluster 내에서 Pod에 접속할 때는 Cluster IP를 이용한다.(Pod는 언제든지 죽고 다시 생성되어 IP가 변경되기 때문)
: Cluster IP로는 Cluster 내부에서만 접속할 수 있다.
: ClusterIP → Pod
2. NodePort
: 외부에서 노드 IP의 특정 포트(<NodeIP>:<NodePort>)로 들어오는 요청을 감지하여, 해당 포트와 연결된 파드로 트래픽을 전달하는 유형의 서비스다.
: 이때 클러스터 내부로 들어온 트래픽을 특정 파드로 연결하기 위한ClusterIP역시 자동으로 생성된다.
: Cluster 내의 아무 Node의 IP에 대한 Port 번호로 접속하도록 한다.
(30,000 ~ 32,767 포트 사용)
: NodePort → ClusterIP → Pod
3. LoadBalancer
: Layer2 ~ Layer4를 지원하는 부하조정 장비 (domain은 Layer7의 Ingress Controller가 처리)
: 클라우드 공급자(Public Cloud)의 로드 밸런서, 외부 장비, Metallb를 사용하여 서비스를 외부에 노출시킨다.
: 외부 로드 밸런서가 라우팅되는NodePort와ClusterIP서비스가 자동으로 생성된다.
: OnPoremises(사내)에서는 외부 LB 장비를 이용하거나 그것보다는 k8s의 Metallb라는 Load Balancer를 이용한다.
Metallb에 사용할 Secret 생성 - kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
** 외부에서 접속할 때 사용되는 IP생성을 위해 ConfigMap 생성 ** - wget http://down.cloudshell.kr/k8s/ConfigMap-Metallb.yaml - vi ConfigMap-Metallb.yaml (## 원하는 대역으로 수정 (기본IP 구성은 10.0.2.200-10.0.2.250인데 사내에 맞게 수정)) - kubectl apply -f ConfigMap-Metallb.yaml ▷ 이제 Load Balancer에 이 IP를 할당한다
Pod Object 특징 : 1개의 pod는 내부에 여러 개의 컨테이너를 가질 수 있지만 대부분 1~2개의 컨테이너를 갖는다. = "고래(Containers)들의 떼"
: 클러스터 내에서 사용할 수 있는 고유한 IP 주소를 할당 받지만, 이 ip는 Service에서 사용하지 않는다. : Pod의 외부에서는 'Service'를 통해 Pod에 접근한다.(Service가 Pod의 Endpoint를 관리한다.) : Pod 내부의 컨테이너들은 네트워크와 볼륨등을 공유하고 서로 localhost로 통신할 수 있다.
상태(State) 관리 : 설정한 Pod 개수 보장,Pod의 livenessProbe(컨테이너가 동작 중인지 여부를 나타낸다. 만약 활성 프로브에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는재시작 정책의 대상이 된다.)
부하 조정(Scheduling)으로 배포 관리 : Pod 배포 시 부하 정도가 가장 적절한 node 선정하여 배포
배포 버전 관리 : Rolling Update (Deployment로 새로운 버전의 App을 이전 버전을 유지한 채 업데이트 진행) + Roll Back (문제 발생 시 이전 버전으로)
Service Discovery (Pod 집합에서 실행중인 Application을네트워크 서비스로 노출하여 Cluster 외부에 있는 User가 Application을 이용하도록 네트워크 경로를 제공하는 것) (K8S는 Pod에게 고유한 IP주소 부여, Pod 집합에 대한 단일 DNS명을 부여.이들간의 로드-밸런싱 수행)
Volume Storage (각 node 별 다양한 storage 제공) (Volume : Pod에 종속되는 디스크. 해당 Pod에 속해 있는 여러 개의 Container가 공유해서 사용)
Kubernetes는 서비스 관리를 개별적이 아닌 집단적으로 관리한다
따라서 대부분의 상황에서 개별 시스템(node)와 상호작용할 필요는 없다
→ 비교적 Stateless(관계의 상태를 유지하지 않는 것) 업무에 적합하다 (stateless 예시 : UDP 프로토콜)
개발 배경
Container는 stateless, immutable, mortal (상태를 가지고 있지 않고, 변화하지 않으며, 언제든 죽을 수 있는)개념을 기반으로 아키텍처를 구성하다 보면 운영에 앞서 반드시 필요한 것이 Container Orchestration(=Kubernetes)이
Container Orchestration은 다수의 Container를 다수의 node(Cluster)에 적절하게 분산 실행하고, 원하는 상태(Desired State)로 실행상태를 유지해 주고, 다운타임 없이 유동적으로 스케일을 확장/축소(Scale)할 수 있게 도와준다
사용자가 Container에 대한 동작과 다른 Container와의 관계를 정의하면 배포/운영/스케일링에 문제가 없도록 자동으로 관리되는 운영 시스템이라고 할 수 있다
Kubernetes 종류
관리형 Kubernetes : Amazon EKS, Azure AKS, Google GKE
설치형 Kubernetes : RANCHER, RedHat OPENSHIFT
직접 구성형 Kubernetes : Kubeadm, Kubespray, Kops, Krib
Kubernetes 설치
설치 구성도
(아래 내용은 master, node1, node2, node3 모두에게 적용)
실행 환경 : centos7-x86_64
1. /etc/hosts 파일 수정
/etc/hosts
각 PC의 IP 작성 후 scp 로 node1,2,3에 복사 - scp /etc/hosts node1:/etc/hosts
2. SWAP 기능 끄기 - swapoff -a - vi /etc/fstab (마지막 부분인 swap 부분 주석처리) - reboot
6. docker 설치 및 시작 - curl -sSL http://get.docker.com | bash - systemctl start docker && systemctl enable docker - docker info | grep -i cgroup (이 명령어 입력 시 Cgroup Driver : cgroupfs라고 나타난다. Kubernetes는 docker의 cgroup을 systemd를 사용하기 때문에 이를 systemd로 변경해주어야 한다)
7. docker cgroup driver를 systemd로 변경 - vi /usr/lib/systemd/system/docker.service (ExecStart=/usr/bin/dockerd 바로 뒤에 --exec-opt native.cgroupdriver=systemd를 삽입) - systemctl daemon-reload (## 모든unit file을reload) - systemctl restart docker - docker info | grep -i cgroup(## systemd로 변경됨)
9. K8S Clustering 구성(Master에서만 작업) #특정한 이전 버전(1.21.1)의 K8S Clustering 구성 - kubeadm init --kubernetes-version=v1.21.1 이때, 설치 결과를 복사하여 다른 곳에 꼭 저장해놓는다. ----------------------------------------------------------------------------
설치 결과 Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
10. Kubernetes 버전 정보 확인 - Master에서 - kubectl version --short - kubeadm version -o yaml - kubelet --version
레파지토리 버전 정보
Namespace 확인 - kubectl get namespaces
- kubectl get namespace
- kubectl get ns
11. Cluster 구성정보(ConfigMap) 확인하기 - Master에서 - kubectl get configmap -n kube-system - kubectl get cm kubeadm-config -n kube-system - kubectl get cm kubeadm-config -n kube-system -o yaml - kubeadm config view
12. Clustering 상태 및 Pod 상태 확인하기 - Master에서 - kubectl get node (## master가 NotReady 상태) - kubectl get pod --all-namespaces (## 모든 pod 확인) - kubectl get pod -A (## 모든 pod 확인)
-->> cluster 상태가 Not Ready이고 coredns 상태가 Pending이다.
이 상태에선 각 Node들에서 실행중인 Pod들간에 통신이 안된다 -->>Pod Network를 생성하여 이 문제를 해결할 수 있다
13. Pod Network 구성하기 - Master에서만 작업 (weave-net 설치) - export kubever=$(kubectl version | base64 | tr -d '\n') - kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever"
- kubectl get pod -A (## coredns가 이제는 running) 30초 정도 기다린 후 - kubectl get pods -A
weave - net - xxxxx 이라는 Pod 이 master 에 설치됨
- kubectl get nodes (## master가 Ready 상태가 됨)
(node1,2,3에서) kubeadm join 10.0.2.15:6443 --token h1a03j.qe1qctd831cfijxa \ --discovery-token-ca-cert-hash sha256:538ab8cea29bab9814f850a87450008bf8ee7efcf3706e562bbc6ce5bb08cf74 입력 후
(master) - kubectl get nodes (## master 말고 node1,2,3도 Ready 상태가 됐음을 알 수 있다)
