쿠버네티스도 결국 써보는구나. 클라우드라 간편해서 좋다. 과금은 좀 무섭지만..
그 다음 작업에는
도커파일로 커스텀 도커이미지 생성
→ 이미지 컨테이너 레지스트리에 올림
→ 쿠버에 airflow 올리기
→ 오퍼레이터 테스트
일단 로컬에서 작업 다 되면.
이번 작업:
google cloud sdk 설치
→ kubectl 설치
→ sample 이미지를 이용해서 container registry에 올림
→ deploy
→ service
→ service, deployment 삭제
→ 그다음 pod 삭제
Google Cloud sdk 설치
sudo apt-get install apt-transport-https ca-certificates gnupg
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
sudo apt-get update && sudo apt-get install google-cloud-sdk
설치된 후 초기설정
glcoud init
kubectl 설치
gcloud components install kubectl
(base) aa@:aa~$ gcloud components install kubectl
Your current Cloud SDK version is: 364.0.0
Installing components from version: 364.0.0
┌─────────────────────────────────────────────┐
│ These components will be installed. │
├────────────────────────┬─────────┬──────────┤
│ Name │ Version │ Size │
├────────────────────────┼─────────┼──────────┤
│ gke-gcloud-auth-plugin │ 0.1.1 │ 3.4 MiB │
│ kubectl │ 1.20.8 │ < 1 MiB │
│ kubectl │ 1.20.8 │ 84.6 MiB │
└────────────────────────┴─────────┴──────────┘
For the latest full release notes, please visit:
https://cloud.google.com/sdk/release_notes
Do you want to continue (Y/n)? y
╔════════════════════════════════════════════════════════════╗
╠═ Creating update staging area ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: gke-gcloud-auth-plugin ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: gke-gcloud-auth-plugin ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: kubectl ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: kubectl ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Creating backup and activating new installation ═╣
╚════════════════════════════════════════════════════════════╝
Performing post processing steps...done.
Update done!
container registry 사용자 인증 과정
sudo usermod -a -G docker ${USER}
gcloud auth login
gcloud auth configure-docker
push한 이미지는 container registry에서 확인 가능.
취약점 스캔 온
올린 이미지 삭제
gcloud container images delete [IMAGE_NAME]
구글 테스트 이미지 deployment → service 해보기
# 배포 확인
kubectl get deployment
# 파드 확인
kubectl get pod
# 파드 살펴보기
kubectl describe pod pod-id -p
# 배포
kubectl create deployment cookie-test --image=gcr.io/google-samples/hello-app:1.0
#배포확인
kubectl get deployment
# 포트노출
kubectl expose deployment cookie-test --type=LoadBalancer --port 8080
kubectl get deployment
No resources found in default namespace.
gcloud container clusters get-credentials my-first-cluster-1 --zone us-central1-c --project ymmu-youtube-analysis
Fetching cluster endpoint and auth data.
kubeconfig entry generated for my-first-cluster-1.
kubectl create deployment lucca-test --image=gcr.io/ymmu-youtube-analysis/lucca_apline
deployment.apps/lucca-test created
kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
lucca-test 0/1 1 0 32s
kubectl get pod
NAME READY STATUS RESTARTS AGE
lucca-test-64c7f68d94-ng6rq 0/1 Completed 3 (27s ago) 43s
kubectl create deployment cookie-test --image=gcr.io/google-samples/hello-app:1.0
deployment.apps/cookie-test created
kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
cookie-test 1/1 1 1 5s
lucca-test 0/1 1 0 117s
kubectl get pod
NAME READY STATUS RESTARTS AGE
cookie-test-6bdf98bcd7-f9bgt 1/1 Running 0 24s
lucca-test-64c7f68d94-ng6rq 0/1 CrashLoopBackOff 4 (40s ago) 2m15s
kubectl expose deployment cookie-test --type=LoadBalancer --port 8080
service/cookie-test exposed
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cookie-test LoadBalancer 10.111.1.221 12,34,56,788 8080:32695/TCP 66s
kubernetes ClusterIP 10.101.1.1 443/TCP 133m
띄운 서버 확인해보기
브라우저(workload)에서 배포 확인
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cookie-test LoadBalancer 10.108.7.221 34.71.114.130 8080:32695/TCP 19m
kubernetes ClusterIP 10.108.0.1 443/TCP 152m
lucca-test ClusterIP 10.108.3.133 7070/TCP 16m
# service 이름은 맞는데 pod는 아님
kubectl delete pod,service lucca-test
service "lucca-test" deleted
Error from server (NotFound): pods "lucca-test" not found
kubectl delete pod,service -l name=lucca-test
No resources found
# 서비스는 이미 내려감
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cookie-test LoadBalancer 10.108.7.221 34.71.114.130 8080:32695/TCP 20m
kubernetes ClusterIP 10.108.0.1 443/TCP 152m
# 포드 확인
kubectl get pod
NAME READY STATUS RESTARTS AGE
cookie-test-6bdf98bcd7-f9bgt 1/1 Running 0 21m
lucca-test-64c7f68d94-ng6rq 0/1 CrashLoopBackOff 9 (2m ago) 23m
# deployment보다 파드를 먼저 지우면 pod가 계속 살아있음
kubectl delete pod lucca-test-64c7f68d94-ng6rq
pod "lucca-test-64c7f68d94-ng6rq" deleted
kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
cookie-test 1/1 1 1 26m
lucca-test 0/1 1 0 28m
# deployment 삭제
kubectl delete deployment lucca-test
deployment.apps "lucca-test" deleted
kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
cookie-test 1/1 1 1 27m
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cookie-test LoadBalancer 10.108.7.221 34.71.114.130 8080:32695/TCP 26m
kubernetes ClusterIP 10.108.0.1 443/TCP 158m
# pod에도 없어짐
kubectl get pod
NAME READY STATUS RESTARTS AGE
cookie-test-6bdf98bcd7-f9bgt 1/1 Running 0 27m
쿠버네티스 파드(POD) 와 노드
Pod
(컨테이너(들)과 컨테이너들이 가지고 있는 리소스들의 묶음. 쿠버에서의 컨테이너 단위라고 생각.)
파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로
파드 내에서 공유하는 컨테이너 자원 종류
- 볼륨과 같은, 공유 스토리지
- 클러스터 IP 주소와 같은, 네트워킹
- 컨테이너 이미지 버전 또는 사용할 특정 포트와 같이, 각 컨테이너가 동작하는 방식에 대한 정보
파드는 특유한 "로컬호스트" 애플리케이션 모형을 만들어. 상대적으로 밀접하게 결합되어진 상이한 애플리케이션 컨테이너들을 수용할 수 있다. (→ 하나의 파드에 도커 컨테이너 여러 개를 들고 있을 수 있음)
- ex. Node.js 앱 컨테이너 + Node.js 웹서버에 의해 발행되는 데이터 공급 컨테이너를 하나의 파드에.
파드 안 컨테이너들은
- IP 주소, 그리고 포트 스페이스를 공유
- 함께 위치하고(동일 IP를 말하는건가?), 스케쥴링 되고 동일 노드 상의 컨텍스트를 공유하면서 동작 (The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.)
- 파드는 쿠버네티스 플랫폼 상에서 최소 단위. 쿠버네티스에서 배포를 생성할 때, 그 배포는 파드를 생성하고 그 안에 컨테이너를 생성 (When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them (as opposed to creating containers directly)
- 각 파드는 스케쥴 되어진 노드 안에 포함되고, (재구동 정책에 따라) 소멸되거나 삭제되기 전까지 그 노드에 계속 있게 됨.
- 노드에 실패가 발생할 경우, 클러스터 내에 가용한 다른 노드들을 대상으로 스케쥴되어진다. (Each Pod is tied to the Node where it is scheduled, and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.)
Node
(간단하게 서버라고 생각.)
- 파드는 항상 노드 안에. A Pod always runs on a Node.
- 쿠버네티스에서 워커 머신임. A Node is a worker machine in Kubernetes and
- 클러스터에 따라 가상머신이거나 물리머신일 수 있음 may be either a virtual or a physical machine, depending on the cluster.
- 각 노드들은 컨트롤 플레인에 의해 운영됨 Each Node is managed by the control plane.
- 노드들은 여러 파드들을 가질 수 있고 쿠버 컨트롤 플레인은 자동으로 클러스터 안의 노드들 사이에서 파드 스케줄링을 담당함 A Node can have multiple pods, and the Kubernetes control plane automatically handles scheduling the pods across the Nodes in the cluster.
- 컨트롤 플레인의 자동 스케줄링은 각 노드의 사용할 수 있는 자원을 고려함. The control plane's automatic scheduling takes into account the available resources on each Node.
- 모든 쿠버 노드들은
- 쿠블릿Kubelet? 이라 하는 쿠버 컨트롤플레인과 노드의 통신을 담당하는 프로세스를 운영함
- 도커와 같은 컨테이너 런타임을 운영. 컨테이너 런타임은 레지스트리에서 컨테이너 이미지를 pull해온다던지 컨테이너를 언팩한다던지, 어플리케이션을 실행시키는 일을 함
싱글 파드 내의 컨테이너들이 강하게 묶여있고 디스크와 같은 자원을 공유해야 하면 함께 스케줄 되어야 함.
Every Kubernetes Node runs at least:
- Kubelet, a process responsible for communication between the Kubernetes control plane and the Node; it manages the Pods and the containers running on a machine.
- A container runtime (like Docker) responsible for pulling the container image from a registry, unpacking the container, and running the application.
Containers should only be scheduled together in a single Pod if they are tightly coupled and need to share resources such as disk.
Node overview
참조