https://velog.io/@pingping95/Kubernetes-Architecture
Subject: 쿠버네티스란?
Kubernetes install: Master 1개, Work Node 2개
쿠버네티스 클러스터 구성
노드 확인 kubectl get nodes
파드 확인 kubectl get pods
-A 옵션을 줘서 모든 파드 확인
모든 네임스페이스 파드 확인
# kubectl get pods -A
# kubectl get pods --all-namespaces 동일
weave-net-~: container network interface CNI
coredns: 2개
k8s-master라고 쓰여진 것 4개
kube-proxy~: 3개
kube-system에 있는건 master나 worker에도 있다?
쿠버네티스 과정에 대한 강의 순서
수업내용
1. 쿠버네티스 시작
[1장] 소개
[2장] 설치
[3장] 컨테이너 실행
2. 기본개념
[4장] 쿠버 아키텍처
[5장] 파드
[6장] 컨트롤러
[7장] 서비스
[8장] 인그레스
[9장] 레이블과 애너테이션
[10장] 쿠버 dns
[11장] 오토스케링
[12장] 파드 스케줄링
[13장] 인증과 권한관리
[14장] 로깅과 모니터링
도커 이용한 어플리케이션 배포 과정
배포해야 할 마이크로 서비스가 수백개인 경우에 사람이 처리할 수 있을까❓
🙅🏻♀️ 수많은 마이크로서비스를 여러 서버에 효율적으로 배치하는 것은 어렵다
쿠버 왜 사용
자동화된 빈 패킹 bin packing
한가로운 노드에 컨테이너를 생성한다
컨테이너화된 작업 실행하는데 사용하는 쿠버네티스 클러스터 노드를 제공
각 컨테이너가 필요로 하는 CPU의 메모리RAM을 쿠버네티스에게 지시함
쿠버네티스는 컨테이너를 노드에 맞춰서 리소스를 잘 사용할 수 있도록 한다
자동화된 복구 self-healing
만약 컨테이너가 5개 있는데 2개가 없어졌다면 자동적으로 2개를 만든다
자동화된 롤아웃과 롤백
버전이 1.1로 해뒀는데 1.2 버전이 있다면 알아서 롤아웃 롤백을 한다
주요 설계 목표
컨테이너로 향상된 리소스 활용의 이점을 누림 + 복잡한 분산 시스템 쉽게 배포하고 관리 가능
쿠버네티스는 여러 개의 컨테이너화된 어플리케이션을 여러서버 (쿠버네티스 클러스터)에 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템
쿠버네티스 클러스터의 정의
클러스터: 여러 개의 서버를 하나로 묶은 집합, 하나의 서버처럼 동작
쿠버네티스 클러스터: 어플리케이션 컨테이너를 배포하기 위한 서버 집합
Control Schedule
Control Manager: 갯수를 보장해줌
Master 노드의 Control Plane
클러스터의 상태를 저장하고 관리
- etcd (key-value data store)
클러스터에 배포된 어플리케이션 실행 정보 저장
- API server
클러스터 상태 조회, 변경을 위한 API 인터페이스 제공
- Scheduler
- Controller Managers
Worker 노드
컨테이너 실행 담당
- kubelet, Container Runtime (Docker..)
- kube-proxy
[1장] 쿠버네티스 소개
오케스트라의 지휘자 역할이라 조타수라고도 부른다
컨테이너를 도커 플랫폼에 올려서
관리 + 운영 + 클러스터 서비스까지 지원
= Container Orchestration
= kubernetes
= k8s
웹 서버에 컨테이너 생성
가장머신VM vs 컨테이너
컨테이너의 목적: 배포
멀티호스트 도커 플랫폼
컨테이너 오케스트레이션
클러스터의 기본동작
① 이미지를 빌드해 Docker hub에 push
② kubectl 명령어 실행해서 Kubernetes API 서버로 REST HTTP 용어를 전달하고 클러스터에 새로운 어플리케이션 컨트롤러 오브젝트 생성
③ 레플리케이션 컨트롤러는 새 파드를 생성하고 스케줄러 (Scheduler)가 워커 노드 중 하나에 스케줄링
④ 해당 워커 노드의 Kubelet은 파드가 스케줄링 된 것을 확인
⑤ 이미지가 로컬에 없기 때문에 Docker에게 레지스트리에서 특정 이미지를 pull 하도록 지시
⑥ 이미지 다운 후 Docker는 컨테이너를 생성하고 실행한다
컨테이너 계층 구조
| Layer 6 | Development Workflow Opinionated Containers |
Openshift, Cloud Foundary, Docker Cloud, Data ... |
| Layer 5 | Orchestraion / Scheduling Service Model |
Kubernetes, Docker Swam, Marathon/Mesos, Nomad ... |
| Layer 4 | Container Engine | Docker, Roket, RunC(OCI), Osv, LXC, LXD |
| Layer 3 | Operating System | RHEL, CentOS, Ubuntu, Unikernels... |
| Layer 2 | Virtual Infrastructure | vSphere, Amazon EC2, GCP Compute Engine, OpenStack ... |
| Layer 1 | Physical Infrastructure | Raw Computer Network Storage |
쿠버네티스
[2장] 쿠버네티스 설치
CNI (Container Network Interface)
Container 간 통신을 지원하는 VxLAN 으로 Pod Network 라고 부른다
쿠버네티스를 사용하기 위해서는 반드시 CNI가 필요하며 다양한 종류의 플러그인이 존재한다
쿠버네티스 클러스터 구성
Master Node (Control Plane)
- 워커 노드들의 상태를 관리하고 제어한다
- Single Master or Multi Master (3, 5개의 Master Nodes)
Worker Node
- 도커 플랫폼을 통해 컨테이너를 동작하여 실제 서비스를 제공
쿠버네티스 클러스터 설치
kubeadm 을 이용한 쿠버네티스 설치
Docker Install (3개 VM 모두)
Kubernetes Install
① 설치 전 환경 설정
② kubeadmin, kubectl, kubelet 설치
③ master node control-plane 구성
④ worker nodes 구성
⑤ 설치 확인
kubectl 명령어 기본 구조
kubectl commands 예제
- kubectl --help
- kubectl command --help
- kubectl run [자원이름] [OPTION]
- kubectl create -f obj.yaml
- kubectl apply -f obj.yaml
- kubectl get [자원이름] [객체이름]
- kubectl edit [자원이름] [객체이름]
- kubectl describe [자원이름] [객체이름]
- kubectl delete pod main
중에 apply는 기존에 있는 거 덮어쓰우기 가능
create는 생성해야하므로 현장에선 apply를 많이 사용한다
kubectl get
kubectl edit : yaml 파일 수정
describe 상세정보 확인
kubectl 주요 명령어
정보 조회
- kubectl get all -A // 모든 개체 정보 출력 (namespaces 무시)
- kubectl get <type> -o wide // 간략정보 추가 확인
- kubectl describe <type> <name> // 세부 정보 추가 확인
- kubectl top <type> // 현재 자원 사용량 확인 (CPU, MEMORY)
- kubectl api-resources // API 확인 (기본 경로: $HOME/.kube/config)
- kubectl logs -f (pod) // 로그 확인
실행
- kubectl run <pod_name> --image=<image NAME> --port=<Port Number> ~ <OPTION> // 단독 pod 실행
- ex) kubectl run webserver --image=nginx:1.14 --port=80
- ex) kubectl create deploy webserver --image=nginx:1.14 --port=80
실행 중 명령
- kubectl delete pods [pod_NAME] // 실행 중인 Pod 종료
- kubectl edit pod [pod_NAME] // 실행 중인 pod 속성 변경 및 적용
- kubectl scale deploy [pod_NAME] ... (수정 옵션) ... // 배포된 서비스 수정 및 적용
- kubectl exec -it [pod_NAME] sh // 실행 중인 pod 터미널 접속 (sh, bash, /bin/bash 터미널 중 하나)
rollout (history / undo / status / pause / resume / restart)
- kubectl rollout history deploy <deployment_name> // deployment 전체 수정 내역 조회
- kubectl rollout history deploy <deployment_name> --revision=(version) // 특정 버전 상세조회
- kubectl rollout undo deploy <deployment_name> // 직전 수정버전으로 롤백
- kubectl rollout undo deploy <deployment_name> --to-revision=(version) // 특정 버전으로 롤백
- kubectl rollout status // deployment 진행상태 확인
- kubectl rollout pause deployment/<deployment_name> // deployment 정지
- kubectl rollout pause deployment/<deployment_name> // deployment 재개
- kubectl rollout pause deployment/<deployment_name> // deployment 재시작
YAML
- kubectl apply -f <yaml file> // YAML 파일 실행
- kubectl delete -f <yaml file> // 실행중인 YAML 종료
kubectl logs -f [pod] //실시간 로그 확인
실행
kubectl run webserver --image=nginx:1.14 --port 80
kubectl create deploy webserver --image=nginx:1.14 --port 80
80은 container port
실행 중 명령
kubectl scale deploy [pod name] <option> 4개의 파드가 생성되어 있는데 하나 더 늘릴 때 scale 명령어 사용함
터미널 접속하려면
[3장] 문제 풀이
[4장] 쿠버네티스 아키텍처
4-1. 쿠버네티스에서 컨테이너 동작 원리
① 사용자가 Docker Push 하여 Docker Machine에서 Docker Hub Site에 image 올린다.
↳ Docker Hub Site가 아니여도 Local repository로 구성을 하여도 된다.
② hub.docker.com 사이트에 있는 docker image를 사용하여 컨테이너 build. kubctl 사용해서 pod를 생성 한다.
- POD 생성시, 사용자에게 요청이 오면 Master API Server로 전달이 되고
API Server는 Docker 에게 사용자가 요청한 컨테이너를 생성해 달라고 Docker 에게 전달 한다. - Docker는 kubelet에서 전달 받은 hub.docker.com 혹은 local repository에서 docker imager를 가지고 컨테이너를 생성 한다.
4-2. Kubernetes Component 🌟
(1) Master용 Component
1) etcd
- 코어OS에서 개발한 고가용성을 제공하는 Key-Value 저장소이다.
- 쿠버네티스에서 필요한 모든 데이터를 저장하는 데이터 베이스 역할을 한다
- 분산 시스템에서 노드 사이의 상태를 공유하는 합의 알고리즘 중 하나인 raft 알고리즘을 구현한 것이다.
- etcd 자체는 꽤 안정적이지만 더 안정적으로 쿠버네티스를 운영하기 위해서는 주기적으로 etcd에 있는 데이터를 백업할 것을 권장한다.
2) kube-apiserver
- 쿠버네티스 클러스터의 API를 사용할 수 있도록 하는 컴포넌트
- 클러스터로 온 요청(Request)이 유효한지를 검증한다. (Validation)
⇒ 클라이언트의 요청에 사용된 토큰이 해당 네임스페이스와 자원을 대상으로 요청을 실행할 권한이 있는지 검사하고 권한이 있다면 특정 오브젝트의 목록을 조회하여 되돌려준다.
( ex. Deployment 목록 조회, .. ) - 쿠버네티스는 마이크로 서비스 아키텍처로 구성되어 있으며 서로 분리된 여러 컴포넌트를 구성되어 있다.
- 쿠버네티스에 보내는 모든 요청은 kube-apiserver를 이용해서 다른 컴포넌트와 통신한다
3) kube-scheduler
- 현재 클러스터 안에서 자원 할당이 가능한 노드 중 적당한 노드를 선택하여 새로운 파드를 실행하도록 선정하는 작업이다
ex) 하드웨어 요구 사항, 어피니티 (함께 있어야 하는 파드들을 같은 노드에 실행하도록 ..),
안티 어피니티 (파드를 다양한 노드로 분산해서 실행 ..), 특정 데이터가 있는 노드에 할당, .. - 파드의 실행조건을 비교하여 최선의 노드를 선택한다
4) kube-controller-manager
- 파드들을 관리하는 Controller
- 모든 Controller를 바이너리 파일 하나로 컴파일해 단일 프로세스로 실행한다.
- 컨트롤러 각각을 실행하는 컴포넌트이다.
- 파드를 관찰하며 갯수를 보장한다
5) cloud-controller-manager
- 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고 해당 클라우드 플랫폼과 상호작용하는 컴포넌트
- Cloud-Controller-Manager는 클라우드 제공자 전용 컨트롤러로 사내 또는 PC 내부의 학습 환경에서는 클라우드 컨트롤 매너지 없음
- 쿠버네티스의 컨트롤러들을 클라우드 서비스와 연결해주는 컴포넌트
- 보통 다음 4가지 컨트롤러 컴포넌트를 관리한다.
- Node Controller
- Route Controller
- Service Controller
- Volume Controller
(2) Worker Node용 Component
1) kubelet
- 클러스터의 모든 노드에서 실행되는 Agent이다
- 정의된 파드 스펙(podSpec)을 받아서 컨테이너가 해당 파드 스펙에 따라 정상적으로 동작하도록 직접 관리한다
(Pod의 실행을 직접 관리하는 뜻)- kubelet은 파드스펙이라는 조건을 담긴 설정을 전달받아서 컨테이너를 실행하고 컨테이너가 정상적으로 실행되는지 헬스체크를 진행한다.
- kubelet은 쿠버네티스를 통해서 생성되지 않는 컨테이너는 관리하지 않는다
- 데몬 형태로 동작한다
2) kube-proxy
- 클러스터의 각 노드에서 실행되는 가상 네트워크를 설정하고 관리하는 네트워크 프록시
- 쿠버네티스 service 구현하는 컴포넌트
- 노드의 네트워크 규칙을 관리하거나 클러스터 바깥에서 파드와 통신이 가능하다.
- iptables rule 구성한다
3) Container Runtime
- 실제로 컨테이너를 실행시키는 스프트웨어
- 쿠버네티스는 여러 컨테이너 런타임을 지원한다
- OCI(Open Container Initivative)의 런타임 규격을 구현한 컨테이너 런타임인 경우 사용가능
- Docker, Crio, Containerd 등이 있다
etcd
kube-apiserver
kube-scheduler
kube-controller-manager
cloud-controller-manager
쿠버네티스 서버와 aws 인프라가 연결하는 ?
kubelet: 노드에 컨테이너 삭제 및 수정
proxy 통신 역할
4-3. Kubernetes Architecture 🌟
1) API
kubectl create
Api 요청 사항
2) etcd
key:value 로 구성 되어 있는 저장소이다.
worker node들에 대한 상태 정보를 가지고 있다. (컨테이너 상태, 이미지 상태)
참고 : node에서 kubelet 설치시 cAdvisor(모니터링)가 Daemon에 포함되어 있어, 상태를 수시로 master에 보고하고 Master Node는 etcd에 그 정보를 저장한다.
3) 사용자 요청
step1. master scheduler에게 요청
etcd의 정보를 참고 하여 해당 node에서 pod를 생성해 줄래 요청 한다.
step2. node1의 kubelet에 요청
step3. kubelet는 docker에게 컨테이너 생성 요청
4) kuber-proxy
network 관련 부분을 처리 한다.
4-4. pod 생성 절차 🌟
요청을 받으면 API Server는 요청이 유효한지 검사 후 etcd에 저장
API Server는 Scheduler 호출해서 스케줄러가 pod를 실행할 위치를 결정 후 API Server에게 전달
API Server는 pods 실행 결과를 etcd에 기록
① kubectl로 create Pod API 호출
② API 서버는 요청이 유효한 지 검사하고 etcd에 저장(그러니까 etcd에 파드가 있는지 물어보는거임)
etcd는 API Server만 통신한다 etcd ↔ API Server
③ etcd가 결과를 리턴(보고하는 느낌)
④ API Server는 Scheduler 호출해서 NEW POD 만들아줘
⑤ Scheduler: 할당되지 않는 pod가 있으면 조건에 맞는 node 할당
⑥ API server는 할당된 정보를 etcd에 기록
⑦ etcd가 결과를 보고
⑧ API Server는 해당 노드에 있는 kubelet 호출해서 pod 스팩 정보 전달하고 생성 요청
⑨ Kubelet는 Docker API 이용해서 컨테이너 생성하기 위해서 hub.docker.com에서 이미지 내려받고 컨테이너 만듦
⑩ pod 상태 업데이트: 생성된 컨테이너를 Kubelet 은 API Server에게 전달한다
⑪ API 서버는 etcd 상태 유지
* API Server, etcd, Scheduler 는 Master에만 있음
4-5. 애드온
추가로 구성 할 수 있는 API (CNI는 kubernetes 설치 시 기본으로 설치 되어 있다.) 얘기 한다.
네트워크 애드온
CNI - weave, calico, flaneld, kube-route
dns 애드온
coreDNS
대시보드 애드온
컨테이너 자원 모니터링
cAdvisor: 각 노드에서 컨테이너가 잘 생성되었는지 CPU, RAM이 얼마인지 모니터링한다
클러스터 로깅
컨테이너 로그, k8s 운영 로그들을 수집해서 중앙화
ELK(ElasticSearch, Logstash, Kibana), EFK(ElasticSearch, Fluentd, Kibana), DataDog
(Web UI ELK 하나로 묶어서 제공)
: 대시보드 와 클러스터 로깅은 기본으로 설치 되어 있지 않다.
4-6. k8s 오브젝트와 컨트롤러
kubernetes namespace란,
논리적으로 분리된 Kubernetes 라고 생각
쉽게 얘기 하면 대한항공 쿠버네티스, 아시아니항공 쿠버네티스 . 기타 항공 쿠버네티스 위와 같이 각각의
(namespace : 대한항공, 아시아나 항공, 기타 항공) 논리적으로 완벽하게 분리됨으로써,
사용자는 하나의 장비에서 여러 대의 쿠버네티스를 사용 할 수 있다고 생각 하면 된다
1) namespace
클러스터 하나를 여러 개의 논리적인 단위로 나눠서 사용
k8s API 종류 중 하나의 Service
쿠버네티스 클러스터 하나를 여러 팀이나 사용자가 함께 공유
용도에 따라 실행해야 하는 앱을 구분할 때 사용 (개인 / 팀 / 워크로드 / 서비스별)
2) namespace Command
$ kubectl create namespace [NAME]
$ kubectl get namespace 네임스페이스 보여줌
$ kubectl delete namespace [NAME] 네임스페이스의 [NAME] 삭제
$ kubectl create namesapce [NAME] --dry-run=client -o yaml > [YAML 파일이름].yaml YAML 파일 형식으로 생성됨
$ vi [YAML 피일 이름].yaml
$ kubectl apply -f [YAML 파일이름].yaml
3) namespace switch
기본으로 사용하는 네임스페이스는 default가 아닌 다른 네임스페이스로 변경
① namespace를 포함한 context 등록
$ kubectl config --help
$ kubectl config [set-context NAME] --cluster=kubernetes --usr=kubernetes-admin --namespace=[NAME]
$ kubectl config view
② 등록된 namespace로 context 변경
$ kubectl config [use-context NAME]
③ 기본 namespace 확인
$ kubectl config [currnet-context]
4) YAML 템플릿
python 처럼 들여 쓰기로 데이터 계층을 표기
들여 쓰기를 할 때 Tab이 아닌 space bar로 표기
scala 문법 : ':'을 기준으로 key:value를 설정
배열 문법 : '-' 문자로 여러 개를 나열
공식 사이트 : http://yaml.org
: yaml은 사림이 쉽게 읽을 수 있는 markup language
5) API version
alpha → beta → stable
kubernetes object 정의 시 apiVersion이 필요
kubernetes가 update 하는 API가 있으면 새로운 API가 생성 됨.
| API Object의 종류 및 버전 | |
| Deployment | app/v1 |
| pod | v1 |
| ReplicaSet | apps/v1 |
| ReplicationControlloer | v1 |
| Service | v1 |
| PersistentVolume | v1 |
[5장 쿠버네티스 pod]
학습내용
pod 개념 및 사용하기
livenessProbe 를 사용한 self-healing Pod 🌟
init container
infra container(pause) 이해하기
static pod 만들기 🌟
pod에 resouce 할당하기 🌟
환경변수를 이용해 컨테이너에 데이터 전달하기
pod 구성 패턴 종류
5-1. Pod 개념 및 사용하기
Container 기본개념
무조건 경량화를 해줘야한다
# cat > app.js
# cat > Dockerfile
FROM node:14 뒤에 경량화할 것 경량화할 때 가장좋은게 alpine?
COPY
ENTRYPOINT
entrypoint 대신에 CMD 넣어줘도 됨
# docker build -t [docker.com ID]/appjs . → dockerfile을 이미지로 build
# docker tag appjs [docker.com ID]/appjs → 이미지에 태그 달아서
# docker push [docker.com ID]/appjs → 이미지를 hub.docker.com에 업로드(push)
build해서 올린 이미지로
kubectl create 어쩌고 replicaset=머신갯수
(1) Pod란,
컨테이너를 표현하는 k8s api의 최소 단위 (최소단위: 배포의 단위. 즉 pod)
pod에는 하나 또는 여러 개의 컨테이너가 포함될 수 있다 (도커에는 컨테이너 쿠버에는 파드)
주문 파드에 원칙은 one 파드에 one 컨테이너 but one 파드에 여러개의 컨테이너 가능 multi container pod
(2) pod 생성하기
① 쿠버네티스에게 웹 서버를 실행해달라고 요청한다
$ kubectl run webserver --image=nginx:1.14② 쿠버네티스의 API가 문법이 맞는지 확인한다
③ node에 대한 정보를 etcd에서 꺼내온다 (각 노드에는 kube-proxy?가 DaemonSet으로 존재하는데 모니터링하는 cAdvisor 덕분에 각 노드들의 정보가 etcd에 저장된다)
④ scheduler를 이용하여 적당한 node를 찾는다
⑤ 스케줄링 중에는 pending 상태라고 한다
⑥ 스케줄링이 완료되면 running 상태가 된다
파드를 생성할 수 있는 방법은 2가지가 존재한다.
- kubectl run 명령으로 생성
- pod yaml을 이용하여 생성
1) kubectl run 명령(CLI)으로 생성
$ kubectl run webserver --image=nginx:1.14
2) pod yaml 을 이용하여 생성 (들여쓰기 / 대소문자)
apiVersion: v1
kind: Pod
metadata:
name: webserver
spec:
containers:
- name: nginx-container
image: nginx:1.14
imagePullPolicy: Always
ports:
- containerPort: 80
protocol: TCP
위와 같이 YAML 파일 생성하고 실행 kubectl 명령어를 입력한다.
$ kubectl create -f [파드이름].yaml // 한번 실행한 파일 존재 시 재 실행 불가능
$ kubectl run -f [파드이름].yaml // 한 번 실행한 파일 존재시 덮어쓰기 가능
3) 현재 동작 중인 pod 정보 확인
$ kubectl get pods
$ kubectl get pods -o wide
$ watch kubectl get pods -o wide // 파드 생성 wide하게 실시간으로 보여줌
$ kubectl get pods -o yaml
$ kubectl get pods -o json
$ kubectl describe pod [pod NAME] // 상세설명
$ kubectl get pods [pod NAME] -o json | grep -i [pod IP] // 해당 파드 IP 주소 확인
$ kubectl get pods [pod NAME] -o yaml | grep -i [pod IP] // 해당파드 IP 주소 확인
$ kubectl get pod [pod NAME] -o yaml > [YAML 파일로 만들 이름].yaml
4) 동작 중인 파드 수정
$ kubectl edit pod [pod NAME]
만약에 YAML 파일로 만든거면 vi 편집기로 수정 가능하다 이때는 kubectl apply -f [YAML 파일 이름].yaml 을 입력해주어야한다
5) pod 접속해서 결과 보기
$ curl [해당 파드 IP Address]
로그확인
kubectl logs [컨테이너 이름]
6) 동작 중인 파드 삭제
$ kubectl delete pod [pod NAME] // 해당 파드 삭제
$ kubectl delete pod --all all // 전체 삭제
$ kubectl delete -f [YAML 파일 이름].yaml // YAML 파일을 통해서 만든 파드나 deploy 삭제할 떄 사용한다
💡 파드 생성해보자!
grep 명령어를 이용해서 IP 주소 확인
현장에서 json보다 yaml 를 더 많이 쓴다
사전에 hub.docker.com 에 나의 계정으로 업로드한 이미지가 있어야 한다
# kubectl create deploy httpd --image=covaltvlue/angel:v1.0 --replicas=3 // deployment로 httpd라는 이름의 파드를 angel이라는 이미지로 3개 생성해라
# kubectl exec -it httpd-67c77d5786-5mblw -- /bin/bash // 해당 파드에 들어가기 exec -it
# kubectl get deploy httpd -o yaml > httpd-deploy.yaml // 생성된 파드 YAML 파일로 얻기 get
# vi httpd-deploy.yaml
그래서 yaml 파일 떠서 수정에 수정을 더해서 사용한다
이를 실행함 !!!!!!!
💡
# cd k8slab/
# cd 5
# cat pod-nginx.yaml 파일 확인 후
# cp pod-nginx.yaml pod-nginx2.yaml → YAML 파일 카피해서
# vi pod-nginx2.yaml → VI 편집기로 수정한다
# kubectl apply -f pod-nginx2.yaml
cp 해서 사용해도 되고
kubectl create -f pod-nginx2.yaml
kubectl get pods nginx-web -o yaml > nginx-web2.yaml
create로 만들어서 get 으로 YAML파일이름.yaml 이렇게 YAML 파일 생성 가능
kubectl run webserver --image=nginx:1.14 -o yaml > webserver.yaml
webserver라는 파드 생성하면서 webserver.yaml 만들기
deploy로 yaml 만들기 가능
kubectl create deploy [디플로이 이름] -o yaml > [NAME].yaml
(3) Multi-Container Pod
하나의 파드에 두 개의 컨테이너가 들어가 있는 것을 멀티컨테이너 파드라고 부르기도 하지만 현장에선 side car pattern?
(4) 멀티컨테이너 파드 생성하기
YAML 파일 예시
apiVersion: v1
kind: Pod
metadata:
name: multipod
spec:
containers:
- name: nginx-container
image: nginx:1.14
ports:
- containerPort: 80
- name: centos-container
image: centos:7
command:
- sleep
- "10000"
1) YAML 파일 실행 (create or apply)
$ kubectl create -f pod-multi.yaml
2) 파드 상태 확인
$ kubectl get pods
$ kubectl get pods -o wide
$ watch kubectl get pods -o wide [뒤에 생략하면 default namespaces] // 실시간으로 보여준다
3) 해당 파드로 진입하기
$ kubectl exec -it [multipod NAME] -c [first Container NAME or SECOND 컨테이너이름] -- /bin/bash
/# curl localhost:[port NUMBER]
/# exit // 빠져나오기
4) 로그 확인
$ kubectl logs [multipod NAME] -c [컨테이너이름]
$ kubectl logs -f [멀티컨테이너 파드 이름] -c [컨테이너 이름] // 스트리밍으로 보기
💡 아까 문제풀 때 멀티 컨테이너 파드를 생성하는 문제를 풀었는데
우리도 확인해보자
YAML 파일 실행
kubectl apply pod-multi.yaml
세션 복제해서 수평 분할 후 watch kubectl get pods -o wide 실시간 파드 상태 확인
해당 파드 진입하기
# kubectl exec [멀티파드이름] -it -c [멀티파드 컨테이너 이름] -- /bin/bash
kubectl exec multipod -it -c nginx-container -- /bin/bash
-c 옵션을 줘야 특정 컨테이너에 들어가기 가능
cd /usr/share/nginx/html 로 들어가서 있는 index.html 파일을 수정해보자
echo "I am HomePage" > index.html 수정 후 cat으로 확인 exit로 빠져나와서
curl 멀티컨테이너파드의 IP 주소를 입력해보면, I am HomePage가 뜬다
특정 로그 점검
원래는 kubectl logs [컨테이너 이름] 이렇게 하면되는데 지금은 멀티 컨테이너라서 멀티컨테이너 파드의 이름이 들어가야 한다
kubectl logs [파드 이름] -c [컨테이너 이름]
스트리밍으로 보려면 -f 옵션 주기 kubectl logs -f [파드이름] -c [컨테이너 이름]
실시간으로 로그 과정 보기
kubectl get pods -o wide --watch
5-2. self-healing Pod
(1) Livness Probe
컨테이너 진단하는 도구
↳ 건강한 컨테이너만 사용하겠다
- Pod가 계속 실행할 수 있음을 보장한다.
- Pod에 문제가 있을 경우, restart를 해준다.
- pod spec에 정의된다
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx-container
image: nginx:1.14
livenessProbe: // self-healing 기능 추가. 주기적인 80포트 접속을 통해 파드 상태 확인
httpGet:
path: /
port: 80
위와 같이 livenessProbe를 추가하면, http 프로토콜을 이용하여 80포트로 접속하여 응답이 잘왔을 경우와 잘오지 않았을 경우를 이용하여 컨테이너 건강 상태를 확인할 수 있다.
위의 예시는 http를 이용한 건강 상태 체크를 수행한다. 건강 상태 수행은 여러가지 방식이 존재한다.
- httpGet 방식 : http Get을 날려 200 상태코드로 응답이 오지 않으면 컨테이너를 다시 시작한다.
- tcpSocket 방식 : 지정된 포트에 TCP 연결을 시도하고, 연결되지 않으면 컨테이너를 다시 시작한다.
- exec 방식 : exec 명령을 전달하고 명령의 종료코드가 0이 아니면 컨테이너를 다시 시작한다.
여러가지 방식으로 상태 체크를 할 수 있는데, 매개변수를 같이 넘겨서 상태 확인을 수행할 수 있다.
웹서버 컨테이너가 있다고 가정하고 이 웹서버 컨테이너에 livenessProbe가 있음
- initialDelaySeconds: Probe가 시작되기 전 대기 시간으로 default는 0초
30초로 가정하면, 컨테이너가 시작된 후 30초 동안 대기한 후에 첫 번째 livenessProbe가 시작 - periodSeconds: default는 10초로 10초마다 웹서버 작동되는지 확인하고 정상적으로 잘 작동되는지 체크함
- timeoutSeconds: default 1초. 5로 설정했다고 가정해 봅시다. 이것은 라이브니스 프로브가 컨테이너의 상태를 확인하는 데에 허용되는 최대 시간을 5초로 제한합니다. 즉, 웹 서버가 5초 안에 응답하지 않으면 프로브는 실패로 간주
- successThreshold: default 1초. 3으로 설정했다고 가정해 봅시다. 즉, 웹 서버가 연속적으로 3번의 성공적인 프로브 후에 정상적으로 동작하는 것으로 간주됩니다
- failureThreshold: 3으로 설정했다고 가정해 봅시다. 이것은 연속적으로 성공적인 프로브 후에 컨테이너를 성공으로 간주하는 횟수를 3으로 설정합니다. 즉, 웹 서버가 연속적으로 3번의 성공적인 프로브 후에 정상적으로 동작하는 것으로 간주됩니다
- terminationGracePeriodSeconds: default 30초. 컨테이너가 종료되기 시작한 후에 얼마나 오랫동안 살아남을 수 있는지를 지정하는 옵션
60으로 설정했다고 가정. 컨테이너가 종료 후 60초 동안 살아있고 시간이 지나면 죽음
파드와 livenessProbe를 넣은 파드 비교
| pod-definition | livenessProbe definition |
| apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx-container image: nginx:1.14 |
apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx-container image: nginx:1.14 livenessProbe: httpGet: path: / port: 80 이 세 개를 묶어서 Self-healing 기능 추가 주기적인 80 포트 접속을 통해 pod 상태 확인 |
* 들여쓰기와 띄어쓰기 대소문자 구분 필요
pod는 node에 만들어진다
워크노드 자세한 정보
root@k8s-master:~# kubectl describe node k8s-worker
Name: k8s-worker1
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=k8s-worker1
kubernetes.io/os=linux
Annotations: kubeadm.alpha.kubernetes.io/cri-socket: unix:///var/run/containerd/containerd.sock
node.alpha.kubernetes.io/ttl: 0
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: Thu, 18 Apr 2024 15:00:16 +0900
Taints: <none>
Unschedulable: false
Lease:
HolderIdentity: k8s-worker1
AcquireTime: <unset>
RenewTime: Mon, 22 Apr 2024 14:04:55 +0900
Conditions:
Type Status LastHeartbeatTime LastTransitionTime Reason Message
---- ------ ----------------- ------------------ ------ -------
NetworkUnavailable False Mon, 22 Apr 2024 09:08:26 +0900 Mon, 22 Apr 2024 09:08:26 +0900 WeaveIsUp Weave pod has set this
MemoryPressure False Mon, 22 Apr 2024 14:01:21 +0900 Mon, 22 Apr 2024 09:08:19 +0900 KubeletHasSufficientMemory kubelet has sufficient memory available
DiskPressure False Mon, 22 Apr 2024 14:01:21 +0900 Mon, 22 Apr 2024 09:08:19 +0900 KubeletHasNoDiskPressure kubelet has no disk pressure
PIDPressure False Mon, 22 Apr 2024 14:01:21 +0900 Mon, 22 Apr 2024 09:08:19 +0900 KubeletHasSufficientPID kubelet has sufficient PID available
Ready True Mon, 22 Apr 2024 14:01:21 +0900 Mon, 22 Apr 2024 09:08:19 +0900 KubeletReady kubelet is posting ready status. AppArmor enabled
Addresses:
InternalIP: 10.100.0.106
Hostname: k8s-worker1
Capacity:
cpu: 2
ephemeral-storage: 25107716Ki
hugepages-2Mi: 0
memory: 2010996Ki
pods: 110
Allocatable:
cpu: 2
ephemeral-storage: 23139271028
hugepages-2Mi: 0
memory: 1908596Ki
pods: 110
System Info:
Machine ID: 2b51f4cfc5a14f97a3bf811bac975781
System UUID: ffacece3-2be1-c447-b460-f03ab63f9291
Boot ID: 6a736ec1-4f76-4bdd-aaba-791e92cc5202
Kernel Version: 5.15.0-105-generic
OS Image: Ubuntu 20.04.6 LTS
Operating System: linux
Architecture: amd64
Container Runtime Version: containerd://1.6.31
Kubelet Version: v1.28.9
Kube-Proxy Version: v1.28.9
Non-terminated Pods: (4 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits Age
--------- ---- ------------ ---------- --------------- ------------- ---
default httpd-67c77d5786-lp4k8 0 (0%) 0 (0%) 0 (0%) 0 (0%) 89m
default httpd-67c77d5786-rrfv9 0 (0%) 0 (0%) 0 (0%) 0 (0%) 89m
kube-system kube-proxy-rwh9n 0 (0%) 0 (0%) 0 (0%) 0 (0%) 3d23h
kube-system weave-net-qfx4f 100m (5%) 0 (0%) 0 (0%) 0 (0%) 3d23h
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 100m (5%) 0 (0%)
memory 0 (0%) 0 (0%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
Events: <none>
Name: k8s-worker2
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=k8s-worker2
kubernetes.io/os=linux
Annotations: kubeadm.alpha.kubernetes.io/cri-socket: unix:///var/run/containerd/containerd.sock
node.alpha.kubernetes.io/ttl: 0
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: Thu, 18 Apr 2024 15:00:22 +0900
Taints: <none>
Unschedulable: false
Lease:
HolderIdentity: k8s-worker2
AcquireTime: <unset>
RenewTime: Mon, 22 Apr 2024 14:04:52 +0900
Conditions:
Type Status LastHeartbeatTime LastTransitionTime Reason Message
---- ------ ----------------- ------------------ ------ -------
NetworkUnavailable False Mon, 22 Apr 2024 09:08:26 +0900 Mon, 22 Apr 2024 09:08:26 +0900 WeaveIsUp Weave pod has set this
MemoryPressure False Mon, 22 Apr 2024 14:00:07 +0900 Mon, 22 Apr 2024 09:08:19 +0900 KubeletHasSufficientMemory kubelet has sufficient memory available
DiskPressure False Mon, 22 Apr 2024 14:00:07 +0900 Mon, 22 Apr 2024 09:08:19 +0900 KubeletHasNoDiskPressure kubelet has no disk pressure
PIDPressure False Mon, 22 Apr 2024 14:00:07 +0900 Mon, 22 Apr 2024 09:08:19 +0900 KubeletHasSufficientPID kubelet has sufficient PID available
Ready True Mon, 22 Apr 2024 14:00:07 +0900 Mon, 22 Apr 2024 09:08:20 +0900 KubeletReady kubelet is posting ready status. AppArmor enabled
Addresses:
InternalIP: 10.100.0.107
Hostname: k8s-worker2
Capacity:
cpu: 2
ephemeral-storage: 25107716Ki
hugepages-2Mi: 0
memory: 2010992Ki
pods: 110
Allocatable:
cpu: 2
ephemeral-storage: 23139271028
hugepages-2Mi: 0
memory: 1908592Ki
pods: 110
System Info:
Machine ID: 2b51f4cfc5a14f97a3bf811bac975781
System UUID: 0c679e21-4f1a-3742-93b5-ebd4acaec6cf
Boot ID: 234d7045-a834-495a-895d-296145c78de0
Kernel Version: 5.15.0-105-generic
OS Image: Ubuntu 20.04.6 LTS
Operating System: linux
Architecture: amd64
Container Runtime Version: containerd://1.6.31
Kubelet Version: v1.28.9
Kube-Proxy Version: v1.28.9
Non-terminated Pods: (3 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits Age
--------- ---- ------------ ---------- --------------- ------------- ---
default httpd-67c77d5786-mlkc5 0 (0%) 0 (0%) 0 (0%) 0 (0%) 89m
kube-system kube-proxy-hq79c 0 (0%) 0 (0%) 0 (0%) 0 (0%) 3d23h
kube-system weave-net-4jnjl 100m (5%) 0 (0%) 0 (0%) 0 (0%) 3d23h
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 100m (5%) 0 (0%)
memory 0 (0%) 0 (0%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
Events: <none>
(2) Liveness Probe 매커니즘
httpGet probe
- 지정한 IP주소, port, path에 HTTP GET 요청을 보내, 해당 컨테이너가 응답하는지 확인
- 반환코드가 200이 아닌 값이 나오면 오류로 인식하여 컨테이너를 재시작한다
- client에서 400이 나오면 오류임
spec:
containers:
- name: nginx-container
image: nginx:1.14
livenessProbe: // self-healing 기능 추가. 주기적인 80포트 접속을 통해 파드 상태 확인
httpGet:
path: /
port: 80
tcpSocket probe
지정된 포트에 TCP 연결 시도
연결되지 않으면 컨테이너 재시작
spec:
containers:
- name: nginx-container
image: nginx:1.14
livenessProbe: // self-healing 기능 추가.
tcpSocket:
port: 22
21 FTP
53 DNS
80 웹서버
WAS 8080
톰켓은 ..? 8080?
3306 DB
exec probe
exec 명령전달하고 해당 파일/계정 /실행명령어가 존재하지 않으면 컨테이너 재시작
spec:
containers:
- name: nginx-container
image: nginx:1.14
livenessProbe:
exec:
command:
- ls
- /data/file
/data/file이라는 파일의 존재 여부를 확인하고 있지만,
이 파일이 존재하지 않거나 권한이 없는 경우에는
컨테이너가 정상적으로 동작하지 않을 수 있습니다.
이에 유의하여 라이브니스 프로브를 설계해야 합니다
(3) liveness Probe 매개 변수
periodSeconds: Health Check 반복 실행 시간
initalDelaySeconds: 파드 실행 후 delay 할 시간
timeoutSeconds: Health Check 후 응답을 기다리는 시간
apiVersion: v1
kind: Pod
metadata:
name: liveness-pod
spec:
containers:
- image: smlinux/unhealthy
name: unhealthy-container
ports:
- containerPort: 8080
protocol: TCP
livenessProbe:
httpGet:
path: /
port: 8080
// 미기재시 default 값 제공
initialDelaySeconds: 15 (default 0)
periodSeconds:20 (default 10)
timeoutSeconds: 1 (default 1)
successThreshold: 1 (default 1)
failureThreshold: 3 (default 3)
미기재시 default 값 세팅
timeoutSeconds: 한 번 실패하면 실패한 것으로 간주
successThresold: 1 이것도 위에꺼랑 똑같은 한번성공하면 성공한 것으로 간주
failureThreehold:
- initialDelaySeconds: Probe가 시작되기 전 대기 시간으로 default는 0초
30초로 가정하면, 컨테이너가 시작된 후 30초 동안 대기한 후에 첫 번째 livenessProbe가 시작 - periodSeconds: default는 10초로 10초마다 웹서버 작동되는지 확인하고 정상적으로 잘 작동되는지 체크함
- timeoutSeconds: default 1초.
5로 설정했다고 가정. 이것은 라이브니스 프로브가 컨테이너의 상태를 확인하는 데에 허용되는 최대 시간을 5초로 제한합니다. 즉, 웹 서버가 5초 안에 응답하지 않으면 Probe는 실패로 간주 - successThreshold: default 1초.
3으로 설정했다고 가정. 웹 서버가 연속적으로 3번의 성공하면 정상적으로 동작하는 것으로 간주됩니다 - failureThreshold: default 3초.
5로 설정했다고 가정해 봅시다. 이것은 연속적으로 실패한 후에 컨테이너를 실패로 간주하는 횟수를 5로 설정합니다. 즉, 웹 서버가 연속적으로 5번의 실패하면 정상적으로 동작하지 않는 것으로 간주됩니다 - terminationGracePeriodSeconds: default 30초. 컨테이너가 종료되기 시작한 후에 얼마나 오랫동안 살아남을 수 있는지를 지정하는 옵션
60으로 설정했다고 가정. 컨테이너가 종료 후 60초 동안 살아있고 시간이 지나면 죽음
root@k8s-master:~/k8slab/5# ls
init-container-exam-svc.yaml init-container-exam2.yaml my-nginx.yaml pod-liveness.yaml pod-mysql.yaml pod-nginx-liveness.yaml pod-nginx.yaml redis.yaml
init-container-exam.yaml liveness-exam.yaml my-pod2.yaml pod-multi.yaml pod-nginx-env.yaml pod-nginx-resources.yaml pod-nginx2.yaml stress.yaml
root@k8s-master:~/k8slab/5# cat pod-nginx-liveness.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod-liveness
spec:
containers:
- name: nginx-container
image: nginx:1.14
ports:
- containerPort: 80
protocol: TCP
livenessProbe:
httpGet:
path: /
port: 80
root@k8s-master:~/k8slab/5# cp pod-nginx-liveness.yaml my-nginx-liveness.yaml
root@k8s-master:~/k8slab/5# ls
init-container-exam-svc.yaml liveness-exam.yaml my-pod2.yaml pod-mysql.yaml pod-nginx-resources.yaml redis.yaml
init-container-exam.yaml my-nginx-liveness.yaml pod-liveness.yaml pod-nginx-env.yaml pod-nginx.yaml stress.yaml
init-container-exam2.yaml my-nginx.yaml pod-multi.yaml pod-nginx-liveness.yaml pod-nginx2.yaml
root@k8s-master:~/k8slab/5# vi my-nginx-liveness.yaml
root@k8s-master:~/k8slab/5# vi my-nginx-liveness.yaml
root@k8s-master:~/k8slab/5#
root@k8s-master:~/k8slab/5# vi my-nginx-liveness.yaml
root@k8s-master:~/k8slab/5#
root@k8s-master:~/k8slab/5# kubectl apply -f my-nginx-liveness.yaml
pod/my-pod-liveness created
root@k8s-master:~/k8slab/5# kubectl get pods my-pod-liveness -o yaml
'☁︎클라우드 > 일자별' 카테고리의 다른 글
| 240424 DAY 75 (0) | 2024.04.28 |
|---|---|
| 240423 DAY 74 (0) | 2024.04.28 |
| 240419 DAY 72 (0) | 2024.04.21 |
| 240418 DAY 71 (0) | 2024.04.21 |
| 240417 DAY 70 (0) | 2024.04.21 |
