240419 DAY 72

yaml 파일 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Kubernetes 클러스터의 모든 노드에 대한 정보 표시

#kubectl get nodes

#su -

#kubectl get nodes

control-plane: master nodes

data-plane: worker nodes

네임스페이스 파드 정보

클러스터 전체의 모든 네임스페이스에 있는 모든 파드 정보 표시
#kubectl get pods -A
#kubectl get pods --all-namespaces
-A 옵션과 동일. 모든 파드에 대한 정보 표시
--all-namespaces: -A의 긴 형식

시스템 파드만 확인
#kubectl get pods -n kube-system
kube-system이라는 네임 스페이스 있는 모든 파드에 대한 정보 표시

네임스페이스 삭제
kubectl delete ns [NAMESPACE_NAME]

#kubectl get pods -A

#kubectl get pods --all-namespaces → 이렇게 쳐도 된다

#kubectl get pods -n kube-system → kube시스템에 있는 pods에 있는 것

-n이 namespaces라는 뜻

master 에만 k8s-master라고 붙은게 보인다

오자마자 모든게 Running되는지 확인할 것

#kubectl get pods -n kube-system

시스템 파드만 확인

#kubectl api-resources

아래에 단축어 외우기

일단 창을 두개로 하고

우클릭 - 세션 복제 - 복제된 탭으로 가서 수평분할

위에 창으로 Running과 IP를 확인하기 위해

#watch kubectl get pods -o wide

kubectl run으로 web이라는 pods(컨테이너) 생성 + 이미지는 nginx 버전 1.14로 생성하겠다

#kubectl run web --image=nginx:1.14

#kubectl get pods → 파드 정보 확인

web 이라는 이름의 pods가 생성이 되었다

#curl [이름 web인 IP주소]

#curl 10.36.0.1 로 확인해보면 아래와 같이 html 나옴

create 명령어를 쓸 땐 deployment를 사용

deployment 를 할아버지라는 웹서버가 만들어진다

deployment를 만드는 순간 부모와 자식이 생성된다

즉 deployment로 create 생성하면 할아버지 + 부모 + 자식이 같이 생성된다

#docker login 해주기

nginx 이미지 사용해서 webserver1이라는 이름의 디플로이먼트 생성
#kubectl create deployment [만들 이름] --image=[웹서버 이름]
#kubectl create deployment webserver1 --image=nginx

kubernetes 클러스터에서 어플리케이션을 배포 및 관리하는데 사용
deployment는 파드 관리, 확장, 축소를 통해 어플리케이션의 가용성 보장

root@k8s-master:~# kubectl create deployment webserver1 --image=nginx

create 명령어로 쓰고 위에 창을 보면 생성된 것이 확인

web: run으로 만든 단독 pods

webserver: Deploy로 만든 pods

webserver 할아버지

7756889c5 부모

뒤에꺼가 자식

어플리케이션의 배포 및 실행 상태 확인
#kubectl get deploy,replicasets,pods

첫번째 NAME 할아버지 , 웹서버의 이름

두번째 NAME 부모

세번째 NAME 자식

아까는 단독pods로 만들거나 이번에 deploy로 만들어도 똑같이 html이 나온다

Kubernetes Deployment 스케일링

#kubectl scale deployment [이름] --replicas=[갯수]
#kubectl scale deployment webserver1 --replicas=3
kubectl scale deployment webserver1: webserver1이라는 이름의 디플로이먼트 스케일링. 클러스터 내에서 어플리케이션을 배포 및 관리하는 쿠버네티스 리소스
--replicas=3: 디플로이먼트의 복제본 수 지정. webserver1이라는 디플로이먼트를 3개의 복제본으로 스케일링
즉, 클러스터에 총 3개의 파드가 배포됨

Kubernetes Control-plane이 디플로이먼트를 업데이트하여 지정된 수의 복제본 생성하거나 삭제하여 스케일링 수행

스케일링

어플리케이션 관리 및 조정
클러스터 내의 파드 수를 조정해서 어플리케이션의 성능, 가용성, 리소스 활용 최적화
수평스케일링 (Horizontal Scaling)
- 어플리케이션의 인스턴스 수를 증가 or 감소시켜 리소스 사용 최적화
- deployment 혹은 replicasets 을 통해 수행
- ex) deployment의 복제본 수를 늘려서 동일한 어플리케이션의 여러 인스턴스를 생성하고 요청이 많은 경우 인스턴스들에 대한 부하를 분산
수직 스케일링 (Vertical Scaling)
- 단일 인스턴스의 크기 조정해서 리소스 사용 최적화
- 주로 컨테이너의 리소스 할당(CPU / RAM)을 조정
- ex) 어플리케이션의 CPU 사용률이 높으면 해당 컨테이너에 더 많은 CPU를 할당하여 성능을 향상시킨다

root@k8s-master:~# kubectl scale deployment webserver1 --replicas=3
deployment.apps/webserver1 scaled

생성한 deployment, replicas, pods 삭제

#kubectl delete [할아버지 / 부모 / 자식 NAME]
이때, rs(replicasets, 부모)와 pods(자식)은 delete해도 상태창을 확인해보면 다시 생성됨
그러므로 deployment(할아버지)를 지워야 삭제가 된다

일단 #kubectl get deployments.apps,rs,pods로 확인

rs: replicasets라는 뜻

#kubectl delete pods [자식NAME]

#kubectl delete rs [부모NAME]

해도 안지워진다 왜냐면 쿠버네티스는 자동으로 생성하는 기능이 있기 때문

그래서 할아버지인 웹서버를 지워야 한다

#kubectl delete deployments.apps [할아버지 이름]

#kubectl delete deployments.apps webserver

#kubectl get deployments.apps,rs,pods 로 확인해보면 webserver1과 단독으로 만든 web 말고 삭제된 것이 확인 가능하다

똑같이 deployment로 생성된 webserver1도 삭제하기

확인해보면 삭제되었다 run으로 생성된 단독 pods인 web만 있음

쿠버네티스 클러스터에서 특정 파드 상세정보를 YAML 형식으로 출력

#kubectl get pods web -o yaml
kubectl get pods web: 'web'이라는 이름의 pods를 가져와라
특정 파드 상태 및 메타데이터 확인
-o yaml: 출력형식 그러니까 확장자를 yaml 형식으로 지정
사람이 읽기 쉽고 이해하기 쉽기 때문에 리소스의 세부 정보 보기 및 수정에 용이

root@k8s-master:~# kubectl get pods web -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2024-04-18T07:37:20Z"
  labels:
    run: web
  name: web
  namespace: default
  resourceVersion: "104784"
  uid: 87218cdc-70ee-4c9d-b972-65a81744c253
spec:
  containers:
  - image: nginx:1.14
    imagePullPolicy: IfNotPresent
    name: web
    ports:
    - containerPort: 80
      protocol: TCP
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-8xwq2
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: k8s-worker2
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kube-api-access-8xwq2
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2024-04-18T07:37:20Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2024-04-19T00:14:10Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2024-04-19T00:14:10Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2024-04-18T07:37:20Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: containerd://debef70fcd556d280b808ca29338d9c2db9d084c37c78233dd5913dad582a86d
    image: docker.io/library/nginx:1.14
    imageID: docker.io/library/nginx@sha256:f7988fb6c02e0ce69257d9bd9cf37ae20a60f1df7563c3a2a6abe24160306b8d
    lastState: {}
    name: web
    ready: true
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-04-19T00:14:09Z"
  hostIP: 10.100.0.107
  phase: Running
  podIP: 10.36.0.1
  podIPs:
  - ip: 10.36.0.1
  qosClass: BestEffort
  startTime: "2024-04-18T07:37:20Z"

#kubectl get pods web -o yaml > web.yaml

kubectl get pods web으로 가져온 web 파드 정보를 yaml형식으로 출력

그 내용을 web.yaml 파일로 저장

#ls 로 확인 후

#cat으로 코드 확인

⚠️ 만약에 yaml 파일이 안 만들어져 있다면 copy (복사)해서 사용해도 된다

#cp web.yaml web2.yaml로 복사해서 #vi web2.yaml로 편집해도 된다

#vi web.yaml로 편집기 열기

name: web2로 변경 (2개 변경하기)

그리고 아주 많은 줄을 삭제하기

⚠️ 들여쓰기 (스페이스바) 제대로 안 넣으면 작동안되기 때문에 주의할 것

그러면 아까 watch 창에 있는 web 말고 web2가 생성된다는 뜻

그리고 #cat web.yaml로 web2로 변경되어 있는지 확인한다

세션복제 해서

#ls 로 'web.yaml' 파일 있는지 리스트 확인

#kubectl apply -f web.yaml → 아까 vi web.yaml에서 name 'web2'로 변경한걸 적용하기 위해서 apply

실행했던 yaml 파일 삭제

#kubectl delete -f web.yaml

#kubectl delete pods [yaml 파일의 이름]도 있는데 그냥 kubectl delete -f web.yaml이게 더 깔끔

create로 webserver라는 이름의 디플로이먼트 생성 + covaltvlue/web:v1.0 이미지 사용해서 컨테이너 배포
* 디플로이먼트: 컨테이너화된 어플리케이션을 관리하고 실행
필요에 따라 자동으로 스케일링 Auto Scaling

#kubectl create deployment [이름] --image=[hub.docker.com ID]/[hub.docker.com에 올린 파일 이름]:[버전]
#kubectl create deployment webserver --image=covaltvlue/web:v1.0
deployment.apps/webserver created

그러면 위에 창에 생성된거 확인

VM 우분투로 가서 'webserver'의 IP 주소 입력하면 내가 hub.docker.com에 올린 index.html 보인다

디플로이먼트 생성 & 복제본 3개로 스케일링

#kubectl create deployment [이름] --image=[내가 받을 hub.docker.com의 계정명]/[받을 파일이름]:[받을 버전]

#kubectl create deployment webserver1 --image=covaltvlue/web:v1.0

#kubectl scale deploy webserver1 --replicas=3

covaltvlue/web:v1.0 이미지 사용 + webserver1이라는 이름의 디플로이먼트 생성

생성된 디플로이먼트의 복제본 수 3개로 스케일링

⇒ 파드의 인스턴스 수 조정하여 어플리케이션의 가용성을 높이는 데 사용

⇒ 쿠버네티스 클러스터에서 어플리케이션을 배포하고 필요에 따라 해당 어플리케이션을 확장하는데 사용된다

#kubectl get deployments.apps,rs,pods 로 확인한다

디플로이먼트의 정보를 yaml 형식으로 출력

이 정보를 yaml 파일로 저장

#kubectl get deployments.apps [이름] -o yaml → 터미널에 yaml 파일의 내용 표시됨

#kubectl get deployments.apps [이름] -o yaml > [yaml 파일 이름] → '>' 사용해서 yaml 파일로 저장

#kubectl get deployments.apps webserver1 -o yaml

#kubectl get deployments.apps webserver1 -o yaml > webserver1-deploy.yaml

kubectl get deployments.apps webserver1: webserver1이라는 이름의 디플로이먼트 상세정보
-o yaml: 출력 형식(확장자 느낌)을 YAML 형식으로 지정.
yaml 형식 - 사람이 읽기 쉽고 이해하기 쉬우며 리소스의 세부 정보를 쉽게 검토 or 수정 용이
yaml 파일은 디플로이먼트의 메타데이터, 스펙 및 상태에 관련된 정보가 포함된다
> webserver1-deploy-yaml: 앞에 명령으로 출력된 결과를 webserver1-deploy-yaml 이라는 파일로 리다이렉트(>)하여 저장
장점 - 디플로이먼트에 대한 상세 정보를 파일로 저장해서 나중에 검토 or 사용 가능

#ls

#vi 편집기로 열어서 수정하고

#cat으로 확인

apiVersion: 디플로이먼트 리소스의 API 버전. 여기서는 apps/v1 사용

kind: 리소스의 종류 지정. 여기서는 디플로이먼트를 정의하고 있으므로 Deployment로 지정

metadata: 리소스에 대한 메타데이터 정의. 여기서는 레이블과 이름을 포함하고 있습니다.

spec: 디플로이먼트의 스펙을 정의. 여기에는 복제본 수, 업데이트 전략 등이 포함

selector: 파드를 식별하기 위한 레이블 셀렉터를 정의합니다.

template: 파드의 템플릿 정의. 여기에는 컨테이너의 이미지 및 기타 설정이 포함

이 파일에서는 Nginx 이미지를 사용하는 파드를 3개 배포하도록 설정되어 있습니다.

(replicas 단어 뒤에 3이라고 적혀있음)

strategy에 RollingUpdate 전략이 사용되며, 업데이트 시에는 최대 25%의 추가 복제본이 허용되고, 최대 25%의 파드가 사용할 수 없습니다.

replicas:3개 머신이 3개라는 의미

그 다음 다시 vi 편집기로 열어서 이름을 webserver2로 바꾼다

생성한 디플로이먼트에 대한 변경 사용 적용 apply

#kubectl apply -f webserver1-deploy.yaml

위에 창으로 확인

이번에는 부모로 rs 만들어보기

이동안 할아버지로 deploy로 만들었으니 부모로 rs 만들건데 명령어가 안 먹혀서 (업데이트가 되었기 때문에)

yaml 파일 만들어서 실행해볼 것이다

그래서

#vi rs.yaml 열어서 복붙

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.14

#cat rs.yaml cat으로 확인

#ls로 파일 있는지 확인하고

#kubectl apply -f rs.yaml 만든걸 적용apply

위에 창으로 확인

replicaset controller에 의해서 만들어진것

web은 단독 pods에 의해서 만들어진것

deployment controller에 의해서 만들어진것

* controller: 갯수 보장. 아까 3개의 머신?을 만들었으니까 지워도 3개를 만든다

머신 갯수와 버전 업데이트 해보기

이번에는 vi로 yaml 열어서

머신갯수 4개로 수정

그리고 #kubectl apply -f rs.yaml 수정한 걸 적용하면

위에 창을 확인해보면 4개로 늘려있다

아래창으로#kubectl get rs rs-nginx

DESIRED 보면 4개로 생성되었다는걸 확인할 수 있다

이번에는 nginx버전을 1.15로 업데이트

버전 업데이트된 걸 확인해보려면

#kubectl describe pods [이름]

#kubectl describe pods rs-nginx-dg88m

nginx버전이 아직도 1.14이다

그래서 이것을 삭제하고 다시 확인해보면 버전이 업데이트되기 때문에 삭제한다

기존꺼 삭제

#kubectl delete pods [삭제할 기존거 이름]

#kubectl delete pods rs-nginx-dg88m

특정 파드 세부 정보 확인

#kubectl describe pods [새롭게 생성된 이름]

#kubectl describe pods rs-nginx-cdn47

이때까지 하나 지우고 업데이트하는게 rolling update

이번에는 deployment로 만든걸 버전을 업데이트할 예정

vi webserver1-deploy.yaml 파일 열어서 편집

원래 내가 hub.docker.com 에 올린 web이라는 이름의 버전이 2.0으로 업데이트 했으면 이렇게 하면 되지만

지금은 업데이트가 안되어 있기 때문에 nginx로 할 예정이다

그래서 Conteriners에

Image: nginx:1.15로

⚠️들여쓰기 똑같이 해줘야함 다르면 error 생긴다

배포(deployment) 이미지 업데이트

#kubectl set image deploy webserver1-deploy.yaml web=covaltvlue/web:2.0

deploy: 디플로이먼트의 줄임말로, 업데이트할 리소스 유형 지정
webserver1-deploy.yaml: 디플로이먼트의 이름이 아닌 디플로이먼트를 정의한 YAML 파일의 경로를 지정
web: 업데이트할 컨테이너의 이름을 지정합니다.
covaltvlue/web:2.0: 업데이트할 이미지의 이름과 버전을 지정합니다.

Kubernetes는 지정된 디플로이먼트에서 web 컨테이너의 이미지를 새로운 이미지로 변경

이러한 변경은 롤링 업데이트의 형태로 이루어지며

기존의 파드를 새로운 이미지로 교체하는 작업이다 → 가용성 유지 + 업데이트 수행

하지만 우리는 nginx:1.15로 바꿨기 때문에

#kubectl set image deploy [deploy controller로 만든 이름] [vi 편집기로 Containers에 있는 Name 의 이름]:[이미지 이름과 버전] --record

#kubectl set image deploy webserver1 web=nginx:1.15 --record

위에 창으로 보면 Terminating으로 교체되고 있는 중이다

#kubectl describe pods [deploy로 생성한 할아버지 이름]-[부모이름]-[자식이름]

# kubectl describe pods webserver1-766d484d4d-5c6sd

Continers Image로 버전 확인해보면 nginx:1.15

∴ deploy에서 갯수보장은 'replicas set'

버전 업데이트가 'deploy'

그래서 아까 replicas 에서 업데이트를 해주려면 일일히 지워서 적용해야 업데이트가 되지만

deploy에서 만든건 자동으로 업데이트가 된다

기존에 만든것들 싹 다 지우기

#kubectl delete --all all

k8slab.zip

0.01MB

zip 파일 풀어서 쉘로 업로드 하고

#cd /home/guru

#ls 로 리스트 확인

#mv k8slab/ /root → 루트로 파일을 옮긴다

cd /k8slab 으로 이동해서

ls로 확인

쿠버네티스 클러스터에 새로운 파드 생성과정 시뮬레이션

root@k8s-master:~/k8slab/5# kubectl run mypod --image=nginx:1.15 --dry-run=client

--image=nginx:1.15: 새로운 파드에 사용할 이미지를 지정합니다. 이 경우 nginx:1.15 이미지를 사용합니다.
--dry-run=client: 파드를 실행하지 않고 클라이언트 측에서만 시뮬레이션하여 파드의 생성을 확인합니다.

실제로 파드가 생성되지 않고 클러스터에서 파드를 생성하는 시뮬레이션만 수행된다

이를 통해 파드가 실제로 생성될 때 어떤 옵션이 사용되는지 미리 확인할 수 있습니다.

이렇게 생성하려고 해도 위에 창에 뜨지 않는다

root@k8s-master:~/k8slab/5# kubectl get pods nginx-pod -o yaml > my-nginx.yaml

root@k8s-master:~/k8slab/5# kubectl run mypod --image=nginx:1.15 -o yaml --dry-run=client

root@k8s-master:~/k8slab/5# kubectl run mypod --image=nginx:1.15 -o yaml --dry-run=client > my-pod2.yaml

#kubectl get pods -o wide라고 해야 IP가 보인다

클러스터 내의 파드 상태 모니터링

#watch kubectl get pods -o wide
기본적으로 2초마다 모니터링된다
여기서 '-n 1' 옵션을 주게 되면

#watch -n 1 kubectl get pods -o wide
watch: 지정된 명령을 주기적으로 실행
-n 1: 업데이트 주기. 1초마다 실행한다는 뜻
kubectl get pods -o wide: 현재 클러스터의 모든 파드에 대한 상태, 정보 조회

#watch get pods -o wide --watch
--watch 옵션을 뒤에 넣어서 파드 상태가 변경될 때마다 해당 정보를 실시간으로 업데이트되는 것을 화면에 표시한다