Client -> Service -> [Load Balancer(L4 스위치 기능수행)] -> pod
하위 객체에 Lable을 달아서 상위객체(service)에서 Selector로 연결
DNS 또한 Pod 형태로 띄워져 있음
Service 객체를 만들면 DNS쪽에 객체가 생성
service의 yaml 명세서 확인
apiVersion: v1 kind: Service metadata: name: test-svc spec: ports: -port: 80 (서비스 포트 80) targetPort: 8080 (pod 안에 expose가 8080 포트 : Service 객체는 80으로 요청오면 8080으로 전달해 줌) selector: run:test
Endpoint Controller
서비스 객체를 만들면 LB 기능을 한다.
그러려면 pod 안에 컨테이너 포트/타겟 포트의 조합을 알아야 한다.
즉 엔드포인트 라는 하위 리소스가 자동으로 만들어 짐
Service Types
- 4가지의 서비스타입이 존재 1.ClusterIP
사설IP 내부통신만 가능
하나의 노드에 부하될 수 있는 문제점이 있음
2.NodePort
ClusterIP + HostPort 서비스 객체를 생성하면 내부적인 iptables 룰셋, DNS 룰셋 등등 [내부 - 외부]간 통신 가능하도록 설정. 누가? Kube-proxy가 한다.
외부에서 내부 pod를 접근하려면 HostPort가 필요
1,2는 온프레미스 환경에서 k8s 구축시 사용
서비스의 iptables를 바탕으로 End Point 를 갖고 노드에 분산시킴
인바운드 리퀘스트를 분산시킴
3.LoadBalancer
NodePort + LB 연동 추가
클라우드 환경에서 k8s 구축시 사용
4.ExternalName
CNAME 레코드
1, 2, 3은 외부 -> 내부pod 접근하기 위한 방법
4은 내부pod -> 외부 서비스를 접근하기 위한 방법
서비스 객체 생성하기
- kubectl expose deployment nginx --port=80 --target-port=8000 : deployment 의 service 객체 생성
1) --port=80 : 서비스 객체 포트 명시 2) --target-port=8000 : pod안의 Container 포트 명시
- 1번째로 ClustIP 타입의 svc 생성 후 확인
root@ip-172-31-4-27:~# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5h2m root@ip-172-31-4-27:~# kubectl get ep NAME ENDPOINTS AGE kubernetes 172.31.4.27:6443 5h3m
1) pod IP : 172.31.4.27 2) api-server port : 6443
- 2번째로 NodePort 타입으로 Service 실행
root@ip-172-31-4-27:~# kubectl expose deployment hwk --port 80 --name web-hwk --type NodePort service/web-hwk exposed root@ip-172-31-4-27:~# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5h16m web-hwk NodePort 10.107.229.55 <none> 80:32472/TCP 4s 해당 IP:PORT로 로 접근한다는 것은 SVC로 접근 한다는 뜻 root@ip-172-31-4-27:~# kubectl get ep NAME ENDPOINTS AGE kubernetes 172.31.4.27:6443 5h16m web-hwk 192.168.82.6:80 13s 해당 IP:PORT로 접근하는것은 pod로 직접 접근한다는 뜻 root@ip-172-31-4-27:~# kubectl get po hwk-66fdbfb65d-smrz5 -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hwk-66fdbfb65d-smrz5 1/1 Running 0 103m 192.168.82.6 ip-172-31-13-180 <none> <none>
- 실제 AWS EC2 public IP : 32472 로 접근이 가능하다. - 순서 : 1) 10.107.229.55:32472 요청 2) SVC는 -> 192.168.82.6:80 의 pod로 접근
- 상위 컨트롤러 -> 하위컨트롤러는 matchLabels를 갖고 연결 - template :
복제하기 위한 정보
RS에서는 DESIRED에 맞게 복제를 수행
이때 template 정보를 갖고 수행
그안에 containers 정보도 있음
pod의 lable 값을 확인 명령어
root@ip-172-31-4-27:~# kubectl get po nginx-6799fc88d8-v9m2z --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-6799fc88d8-v9m2z 1/1 Running 0 7m46s app=nginx,pod-template-hash=6799fc88d8
-o wide 옵션 주면 selector 정보 확인
root@ip-172-31-4-27:~# kubectl get rs nginx-6799fc88d8 -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR nginx-6799fc88d8 1 1 1 8m25s nginx nginx app=nginx,pod-template-hash=6799fc88d8
RS에서 pod를 컨텍하기 위해서 SELECTOR -> LABELS가 매치되어 있는것을 확인 할 수 있다.
root@master1:~# kubectl get event LAST SEEN TYPE REASON OBJECT MESSAGE 2m30s Normal Scheduled pod/mypod Successfully assigned default/mypod to ip-172-31-4-27 2m30s Normal Pulling pod/mypod Pulling image "nginx" 2m26s Normal Pulled pod/mypod Successfully pulled image "nginx" in 3.59835338s 2m26s Normal Created pod/mypod Created container hwk 2m26s Normal Started pod/mypod Started container hwk
Cluster 구성요소 (참조 : kubernetes in action)k8s 설치 이후 구성요소 확인
Deployment Controller 기반
Deployment 기반 배포란? - 가장 범용으로 사용 - Deployment 라는 상위 기반을 생성 - 하위 컨트롤러를 하나 더 소유 (Replica Set 컨트롤러) - Replica Set 은 Pod를 버전 별로 관리 - 예를 들어 Node에 문제가 발생한 경우, Pod를 재배포 하면 된다
