Pod

쿠버네티스가 배포할 수 있는 가장 작은 단위

쿠버네티스는 컨테이너를 배포하는게 아니라
pod(팟, 포드)을 배포하는 것임

pod의 특징은
각 pod마다 고유한 ip를 부여받기 때문에 ip를 통해 내부적으로 통신이 가능하다.

보통 팟에는 컨테이너가 한 개 있지만, 두 개가 있을 수도 있음
그림에서는 컨테이너가 두개인데,

🎇팟으로 묶여있으면 host 폴더를 공유할 수 있고, localhost 네트워크 포트번호를 공유할 수 있음 ㅋㅋㅋ

Replicaset

리플리카셋은 여러개의 팟을 관리하는 단위이다.

몇 개의 pod을 관리할 지 결정하는 것.
replicas가 3이라면 pod이 3개여야한다.

Deployment

deployment는 리플리카셋을 감싸는 애인데,
버전관리할 때 이용한다.

만약 원래 리플리카셋이 버전1이었는데
deployement의 버전을 2로 설정한다면,
pod을 한번에 버전 2로 뿅! 하고 바꾸는게 아니라,

하나씩 버전2로 업해준다.

ClusterIP

clusterIP는 로드밸런서의 역할도 하는데,
pod은 뿅 하고 생겼다가 뿅 하고 사라지는 그런 개념이라
계속 ip주소가 바뀐다.

그래서 pod을 무조건 clusterIP에서 연결해주고 있다.

그치만 clusterIP는 내부에서만 통신할 수 있기 때문에,
외부 브라우저에서는 접근이 불가하다.
그래서 노드포트라는 개념이 나타났다

NodePort

nodeport를 통해 웹 브라우저에서도 서비스에 접근이 가능하다
모든 노드가 동일한 포트로 생성되기 때문에
1번 node로 가던, 2번노드로 가던 상관없다.
그리고 또 잘 알아서 찾아가 준다.

그런데, 만약 로드밸런서가 없다면
웹 브라우저가 처음에 무조건 node01로 가게 해놓고 node01에서 알맞은 node 번호로 이동하게끔 해줘야한다....

근데 node01번이 죽어버린다면...?

이런 문제 때문에 로드밸런서를 두어
웹브라우저가 로드밸런서를 거쳐 node에 접근하도록 하고있다.

Ingress

loadbalancer는 포트번호로 찾아가는데,
ingress 같은 경우에는 도메인에 붙는 /path로 찾아간다.
완전 @Controller 같은 느낌이군 ㅋ

🎇일반적인 구성

일반적으로는 pod을 우리가 생성하는게 아니고,

• deployement를 생성하면

• replicaSet이 생성되고 pod도 생성됨

• 그러면 pod끼리 통신할 수 있게 하기위해 clusterIP를 붙여준다.

• 그리고 웹 브라우저에서 접근하게 하고싶으니까 ingress를 붙여준다.
  ingress를 붙이면 loadBalancer는 자동으로 따라오고, 자동으로 nodeport도 따라옴.

  web에서 서비스 url로 접근하면 loadBalancer가 nodePort로 이어주고
  nodePort가 clusterIP를 통해 pod과 이어주는 방식이다.
  이게 바로 쿠버네티스의 동작방식!