Pod

하나 이상의 컨테니어로 구성된 최소 배포 단위
기능을 묶어놓은 단위로 생각하면 좋다

Static Pod

kublect이 설치된 디렉토리에 yaml 추가를 하여 API-scheduler를 통해 동작되는게 아니라
API에게 바로 동작 명령을 받은 뒤 실행 되는 pod
즉 API의 도움 없이 kublect daemon에 의해 실행되는 pod

control plane 제외 하위 노드에서
cat /var/lib/kubelet/config.yaml 을통해 staticPodPath 확인
kubectl delete por --all로 pod 삭제 먼저 진행
staticPodPath에 yaml 파일을 등록
cat pod-ngnix.yaml

static pod 삭제

rm ngnix.yaml
staticPodPath에 등록된 yaml 파일 삭제

resource 할당

pod별로 resource 할당을 하지 않으면
한 노드에 있는 머신의 리소스를 하나의 파드가 전부 사용할 수 있기 때문

Resource Request

파드를 실행할 때 필요한 최소한의 리소스 양을 스케줄러에게 요청

Resource Limits

파드가 사용할 수 있는 최대 리소스 양을 제한
메모리 리밋을 초과하면 자동으로 파드가 종료되며 스케줄링됨

pod의 yaml파일에 할당할 메모리를 추가해준다

resources:
  limits:
    memory: 500Mi
    cpu: 300m

메모리, cpu 단위 더 공부할 것

Pod의 환경변수

마찬가지로 yaml 환경설정 파일에서 진행

env:
- name:
  value:

이해가 잘 안되는점

도커 - k8s - pod - 컨테이너를 통해 자바 스프링 기반 사이트를 배포한다고 가정하면
자바로 웹 작성 뒤 war나 jar로 압축 뒤 도커클라우드에 올림
👉 마스터 플레인에 war 이미지를 받음 👉 각각 기능들은 노드에 할당???
실제 업무에서 aws로 배포 뒤 수정사항이 생기면
코드 수정 - 재배포가 아니라 기능별로 pod로 쪼개서 진행하는 것??