데이터센터프로그래밍22(1)

22-Services(이론)

🟡 공부할 내용

• 쿠버네티스의 서비스란?
• 서비스를 사용하는 것이 왜 중요할까?

🐶 복습

• Pods
  : 쿠버네티스에서 가장 기본적인 서비스
  : 쿠버네티스에서 Pods의 수명은 필요할 때 생기고, 필요없어지면 죽는데, 기본적으로 Pods은 몇개 살아있고 죽는지에 대해서 예측하기 어려움 (컴퓨터의 성능에 따라 다르겠지만...)
  : 처음에 서비스(ex. replicasets)가 시작이 되었을 때, 필요한 만큼의 pods를 만든다
  : but, pods가 동작을 하다가 죽을 수 있다
  : 만약, 시스템의 문제가 있거나, 버전 up & down을 통해서 pods가 중간에 사용자가 모르는 상황에서 죽었다가 살아날 수 있다 (단, 죽었다가 살아날때, 같은 pod가 살아나는 것은 아님!! 즉, 완전 새로운 pod가 나타남)
  : 🙂 따라서, pods는 scaling up & down이 가능하며, pods는 동적이기 때문에 ip address가 의미없다
  : 🙂 Frontends란? pod가 하나 죽고, 하나 살아난다고 했을 때, 앞에 있는 애들에게 ip address로 관리하라고 한다면? 살았는지, 죽었는지 관리하는 것이 힘들것이라는 것을 통상적으로 하는 말 (pods 앞에 있음)
  ex. 노트북이나 핸드폰처럼 요청하는 것이 Frontends 이며 Frontends 뒤에 있는 것을 backend라고 함
  ➡ Frontends가 받아서 backend에게 전달함
  ➡ 🙂 Pods는 앞에서(Frontends) 요구를 받기도하고, 뒤에서(backend) 요구를 작업하기도 함
  💡 앞에 있는 Pods는 뒤쪽에 있는 Pods는를 어떻게 받을 것인가?
  📢 labels & selectors

🟡 Services

• Pods, ReplicaSet, Deployment 위에 Services를 쌓는다
• 쿠버네티스에서의 Service는 추상화개념으로 pods의 Frontends & backend를 연결하는 logical한 pods이 존재할 때에 이들을 연결하는 policy를 서비스라는 이름으로 정의
• Pods를 yaml으로 만들어서 실행했고, ReplicaSet & Deployment를 해보았다
• node port가 서비스에 속하며, infrastructure as code의 철학에 따라 yaml or json 파일을 가지고 만든다
• Pods를 yaml으로 만들어서 실행했고, 그 Pods를 모아서 서로 다른 이미지의 Pods를 모으고 ReplicaSet을 만듦
• 이를 확장하여 Deployment를 만들었는데, Services는 이보다 상위개념이다
• 서비스를 통해 필요한 pods를 묶어서 필요한 동작을 하게 하다가 동적으로 바꾸기도 할것임
• label을 필요할 때 호출하는데 서비스가 살아있을 때, 명령을 주고 호출할 수 있고, 중간에 서비스들을 제어하는 용도로 labelselector를 많이 사용할 것이다

🟡 Services & pods

• 초록색 상자 안에는 frotend라고 불리는 pod이 있다
• version 1 & version 2의 pod이 있다
• 초록색 상자 안에 작은 상자는 label을 의미한다
• 만약, 어플리케이션을 도입했는데 version 1인데 2로 넘기는 방법은..
  : (1) version 1을 멈추고 version 2로 실행
  : (2) version 1이 3개라면, version 2에 한개를 만들어서 넘기고, version 1의 1개를 죽이는 방법
• 버전이 다른것은 문제가 없으며 프로그램이 실행되기만 하면 됨
• 그림 설명) frontend service가 외부에서 tropic("https"433-외부적으로 공개되어있음)을 받아서 별도로 프로그램을 짜지않고 automatic하게 쿠버네티스가 default(실행x)해주는 load balancing(한개씩 주는것)하는 형태를 보여준다
• 🙂 즉, 기능적으로 frontend service가 기능적 frontend이며, 뒤에있는 초록색 box가 backend가 됨
  

🟡 Services pods & replicas (1)

• 그림 설명) replica(RC)는 version 1 이미지를 다루고 있는 controler인데, 보라색 상자를 보면, Desired count를 왼쪽 2개, 오른쪽 1개 잡은 것을 볼 수 있다
  

🟡 Services pods & replicas (2)

• version 여러 개가 한꺼번에 여러개 돌지않는다 (그 이유는 Immutable(변하지x) 상태를 원하기 때문이다)
• 그림 설명) version 1 에서 version 2로 넘기려는 모습을 볼 수 있다
• frontend service에서 version 2로 하겠다고 했으니, version 2만 있는 것을 볼 수 있음
• 🙂 즉, 서버스를 통해서 외부와의 통신, 아래있는 pods를 서비스라는 컨셉에서 어떻게 끌어안을 것인지, 중간에 있는 것을 어떻게 traffic하게 pod로 policy할 것인지?
  

🟡 Services (추가설명)

• pods이 ip address를 가지고 있지만, cluster 밖으로 보이는 것이므로 의미가 없다
• 외부로 보이지 않으니, 내부와 외부를 통신할 수 있는 구멍을 뚫어야한다

🟡 ServiceSpec (1)

• 네트워크 or pods를 묶어주는 것을 총지칭함
• 쿠버네티스를 사용해서 simple pods도 만들고, replica, deployment까지 공부를 했는데, 많은 것을 쿠버네티스에서 해주고 있다
• 🐶 clusterIP service
• clusterIP service : pods를 만들고 외부에서 curl을 통해서 접속을하고 load balancing을 통해서 전달이되고, pod은 서로 자신의 이름을 써서 통신도 된다 이것을 최초로 해주는 default 쿠버네티스 서비스의 이름을 clusterIP service라고 한다
• clusterIP service : 외부에 통신을 할 때, node-port를 뚫은 것처럼 external access는 별도로 없다. 그래서 외부와 통신을 하지않고, 내부적으로 pods들 그리고 이것을 사용하는 Replication Control or deployment로 충분하다면 clusterIP service를 사용함
• 🐶 Node port
• ATTP를 컨테이너 이미지로 띄워서 접속을 하지 않을 때에는 Node port를 띄우는 일도 없다
• Node port : 외부에서 구멍을 뚫어서 안으로 들어가는 것으로 external하게 traffic이 내가 만든 서비스와 어플리케이션이 들어올 수 있도록 하는 것이다
• Node port : cluster를 구성하는 node에 구멍을 뚫어주는 것이다
• Node port를 사용하면, 외부에서 들어오는 traffic이 받는 port 1개를 열게되는 것이다
• 이 port로 들어오게 된것을 뒤에있는 pods들을 누구에게 줄 것인지도 Node port를 통해서 정리할 수 있다

🟡 ServiceSpec (2)

• 🐶 LoadBalancer
• 일반적으로 LoadBalancer를 사용한다
• LoadBalancer : port numbder를 뚫는 것이 주요 목적이므로, node port가 있음
• LoadBalancer : 자신이 받은 default는 외부와의 구멍을 뚫어서 받는 것이다 (뒤에 있는 애들에게 얼마나 잘 전달할 수 있는지에 대해 더 많은 기능을 가지고 있는 것이 LoadBalancer이다)
• 실제로 물리적으로 컴퓨터가 분리되어 있는 경우에만 동작을 하기 때문에 현재 경험할 수 없다
• GKE 검색 후, [Google Kubernetes Engine]사이트에 접속해보기 https://cloud.google.com/kubernetes-engine/?utm_source

💗 정리

• clusterIP service : 외부에 interface가 없는 로컬 환경에서 만들어주는 네트워크를 포함한 서비스
• Node port : 외부와 interface가 되며 Vircher Machine들을 사용해서도 사용할 수 있는 서비스
• LoadBalancer : 별도의 컴퓨터가 존재해서 물리적으로 분리가 되었을 때, 사용할 수 있는 서비스
• Ingress : type of service가 아니며, smart router or entrypoint하다 (외부와 연결하기 위한 구멍 or 정보를 받았을 때 누구에게 줄 것인지를 똑똑하게 사용할 수 있다)