clusterIP
loadBalancer
쿠버네티스의 고유명사 service
서비스라고 얘기하지만 가장 많이 사용하는 네트워크기능이며 ip address안쓰기위한것 pod. 죽었다 살아나고 desired state에 있는것처럼 새로 생성해준다. 부활이 아니라 완전히 새로운 애가 생겨나기때문에 기존 애의 ip address등이 소거됨 그래서 같지 않다. 그래서 ip address로 서비스를 구성하지 않는것이다. docker에서는 개발용이고 내가 만들고 내가 죽이는거고 deployment controller replica controller가 실행하고 관리하는 것이기 때문에 개발자는 모른다. ip address를 가지고 짤 수 없으니 label을 쓴다. pod앞에있는 frontend라고 부르는 컨테이너에게 넘기는데 앞에 있는 서버는 어떻게 뒤에 있는 컨테이너를 식별할까? label
앞에서 대장역할하면서 요청 받아서 뒤에 있는 애들에게 전달하는것을 service라고 부른다
추상화되어있다. 외부에서 내부를 접근하려고 할때 어떻게 접근하게 할것인지 정책을 세우고 수행한다.
yaml으로 pod을 만들어서 실행했는데 사용자의 요구를 받아서 뒤에있는 컨테이너에 뿌리는 serviec도 yaml파일로 만든다. pod을 생성하는 게 아니라 이미 쿠버네티스 안에 만들어져있다 네트워크 프로그래밍되어있는걸 공유한것.
pod들로 이루어진애들을 deployment controller가 실행시킨다
yaml파일로 웹브라우저가 요청하면 받아서 넘겨주는 등 pod들에게 넘겨주는 애가 service이고 yaml파일에 기술할거다
앞에 서비스가 요청 받고 뒤쪽인 pod들에 뿌려준다 서비스는 pod들을 label로 식별한다
서비스가 받아서 뿌린다. label을 기반으로
기본적으로 load balancing해준다
통상 reverse proxy load balancer, dispatcher라고 했던 애를 직접 만들지 않는다 쿠버네티스가 만들어놓은걸 쓴다
http리퀘스트를 최초로 받는애 nginx였는데 그걸 안쓰고 쿠버네티스가 제공한다
pod들은 deploy하면서 deployment컨트롤러가 replica controller는 yaml파일 받았고
하나의 서비스에 대해서 두개이상의 컨트롤러로 두개이상의 pod을 운영할수 있는경우 ⇒ 새로만든 서비스가 만족도가 높을지 모르기 때문에 30퍼센트의 고객에게 새로만들어진 화면을 보여줘서 고객이 관심이 높아지는것을 재본다 해보지 않았을때에 알수없으니 다른 서비스 만들어서 소규모의 focusing된 그룹에게 해본다
100퍼센트 바꾸자 하면 rolling
rolling update하는과정이라 볼수도 있지만 테스트해보고 있는 과정이라고 볼수있다
프론트엔드 서비스가 버전1버리고 2로만 간다 service라벨을 2로 바꿔버리면 된다
ip address를 쓰지 않는다는거 이름을 쓰는 기술적 방법 label