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
서비스는 뒤에있는 pod을 선택하기 위한 방법
pod들은 ip주소 있지만 외부에 오픈할수없다 의미가 없다 죽기 때문에
서비스를 앞에다 세워서 외부에서 오는 트래픽을 받아서 일할 애들에게 전달한다
서비스는 다양한 기술에 의해서 구현 가능함 clusterIP서비스
docker compose와 docker swarm은 DNS가 동작하고 있다 컨테이너마다 이릉미 부여되어있고이름이 DNS에 등록되어있다
쿠버네티스가 노드를 묶어서 클러스터를 만드는데 각각의 노드나 pod들이 서로를 식별할수있는 clusterIP서비스
클러스터 안에서만 유효하다. 이ip를 통해서로를 식별할수있다 개발이나 디버깅할때는. 하지만 운영할때는 쓰지않는다
serviceSpec
클러스터 구성하는 노드중 하나에 구멍을 뚫은것
vm들에 구멍을 뚫었다 트래픽이 들어가면 그것들을 하나로 묶는다
자연스럽게 서비스 안으로 들어간다. 지정된 label에 의거해서 pod에 전달한다
nodeport
노드들에 구멍을 뚫었는데 들어온 트래픽을 받아 정해진 라벨에 의해 보낸다
구멍을 뚫어서 트래픽 주고받아야하는 케이스는?
nodeport를 쓸수있는 전제조건?
컴퓨터에 구멍을 뚫었다 보안상 열려있으면 위험한데
nodeport는 믿을수있는 사람의 traffic만 유입이 되어야한다
언제 nodeport를 실행하면 될까. 신뢰할수 있는 traffic만 유입되어야한다
고객을 받는게 아니다
load balaner
local env에서는 workign하지 않는다.
master slave관계로 클러스터 구축했을때만 돈다
외부의 사용자로부터 받은 load를 뒤에있는 pod들에게 나눠준다
인터넷에 service를 expose한다
ip address가 외부에 노출된다
죽을수 잇으니 접근하지 말아라 nat/pat private ip를 public ip로변환하는것
ipaddress가 모자라니까 그 ip몇개가 안되니까
외부적으로 공개할수있는게 별로 없을테니까
로드밸런서에는 알고리즘이 개입되고 어떤 알고리즘 쓰냐에 따라 성능이 다르다
여러 정책을 펼 수 있다.
request를 앞에서 받는다 nginx를 여기에 주로 썼는데 security도 있고 캐싱도 하지만 결국은 뿌려주는거고 이걸하기 위해서 로드밸런서를 쓴다
Ingress
서비스 아니다 사실은
pod들이 있고 창구 역할을 하는 서비스들이 있고
로드밸런서는 받아서 서비스에 분배하는 역할이었는데
트래픽이 들어오면 도메인에 따라서 밸런싱
네트워크 프로그램 짜서 배치하고 하는거였는데 ingress라는 이름으로 쿠버네티스가 준다 smart router
ip패킷 왔을때 적합한곳으로 보낸다.
길 정리해서 가야할 곳으로 보내는것
도메인 이름에 따라 정해진 서버쪽으로 보내는 애다
쿠버네티스는 클러스터로 감쌌을때 clusterIp주고 필요할때 디버그하거나 할때 쓰라고 준다.
nodeport는 제대로 작동하는지 테스트하거나 내부적으로 안정적으로 모니터링 등을 해야할때 사용한다. 운용이 아니라 개발용으로. 유저는 믿을 수 없기 때문에
상용서비스는 ingress가 정책에 따라 결정해준다
kind service
type nodeport
어떻게 포트 열건데 ports: name http 80
http용도로 열었다
clusterIP서비스가 자동으로 생성되어있다
10 96 17 153은 접근할수있는 소프트웨어!
1은 스위치나 라우터 대장이다
selector app키는 eva release키는 west
kubectl�run�-i�--rm�--tty�debug�\�
--image=alpine:latest�--restart=Never�--�ash�-il�
apk�add�curl�
curl�http://eva/
노드들을 묶어서 가상의 클러스터 만들고 pod들을 실행 nodeport로 감싸가지고 nodeport의 번호면 들어가게 한다 클러스터 안에 있는 애들은 dns서비스로 묶여있다 같은 클러스터 안에서 pod을 만들고 같은 클러스터는 dns로 묶여있는지 확인해보는것
log명령
load balancing한다고 얘기했는데 kubectl로 로그명령 west두개에게 주니까
nginx앱의 로그를 보여달라.
실제로 nodeport로 로드밸런싱 되어있는지 확인
cluserIP란 무엇인가
쿠버네티스 클러스터 바깥에서는 접속할수없는 내부에서만 의미있는 애들
같은 ip안에 있는 애들끼리 통신할수있다
deployment에 nginx두개띄우고
애시당초 서비스 kind를 clusterIP로 한거 두가지. selector에 의해서 nginx를 선택한다.
앞에다가 서비스를 세우고 http용도로 80번 열겠다 한후 nginx에게 넘긴다
두개의 pod이 존재 외부의 bash shell안의 nginx pod 대화시킴
Nodeport
서비스의 외부
포트번호가 정해져있다
cluserIP는 자기들끼리 사용하는거
노드에다 포트를 뚫었으니 외부에 열린포트 치면 접속가능
tunnel 미니쿠베는 터널을 뚫어놓음
쿠버네티스에 있는 모든것들은 원래 있었거나 편리하게 해주는것들을 넣어놓은것
외부로부터 request를 받아서 뒤쪽에 있는 pod들에게 전달하는 service를 어떻게 구현할까?
ip패킷이 오면 서비스는?
실제로 내부적으로는 pod같은건 없는데
전달하는 방법은 ip패킷밖에 없다
label은 사설 ip로 바뀐다
iptable을 관리하면서 사설ip들을
round robin형식으로 ptr를 관리하면서 하나씩 증가하면서 돌아가면서 준다
왼쪽이 public 오른쪽이 private nat/pat
가상 ip와 iptable을 사용한다
로드 밸런서가 round robin하는데 각 pod마다 load가 다르면..?
ip를 안보는건 개발,운영자지 내부적으로는 ip로 동작한다 당연히
뒤에있는애가 누구고 얼마나 힘들어하는지 알고있다 뒤에있는애와 정보를 주고받는 과정이 있다.
virtual server 속도가 엄청 빨라야한다. lookup 찾고 hash로 내보내면 되는데 logic이 들어와서 다른애들 정보를 동적으로 가져오고 프로그램이 돌아서 가능한 빠른시간에 내보내야한다. 테이블이 아닌 방식으로 서비스를 구현 굉장히 전통적인 관문에 있어서 뒤에있는 애들을 전처리하는 virtual server
iptable, virtual서버 하이브리드. nat/pat를 짤때쓴다 그거보다 더 복잡한게 보안 알고리즘 올린 firewall.
쿠버넽스의 서비스가 ip로 들어오는 트래픽을 kube proxy에 의해 인터셉트
