※주의
이 글은 제가 혼자 공부하면서 여기저기 찾아보고 정리하는 곳이라서
글의 퀄리티나 내용상 맞지 않는 부분들이 있습니다.
공식문서가 더욱 더 큰 도움이 될 수 있습니다!
궁금점
레플리카셋이 만약에 3이면 3개의 pod를 동시에 실행하는 것인데,
동시에 실행한다라는 말이 조금 와닿지 않는다.
그리고 동시에 실행했을 때 어느 하나의 pod에 접근을 한다면 3개중에 어느 pod에 접근을 하는 것인가?
또, 세 개중 하나가 오류가 나서 재실행을 할 때에는 정확히 어떤식으로 동작하는가?
행동
정말 궁금했던 내용들인데.. 위의 궁금점들이
공식사이트의 ReplicaSet 파트에 나오는 것이 아니라,
ReplicaSet으로 생성된 복제된 pod들의 HTTP 요청에 대한 내용은 Service에서 나온다고 합니다..
아직 쿠린이라서 너무 어렵네요..
외부에서 Service를 통해 분산되어 있는 Pod Replication에 요청이 balancing된다 라고 보시면 됩니다!
복제 된 pod 접근에 대한 얘기
쿠버네티스 클러스터의 모든 노드는 kube-proxy를 실행합니다.
proxy의 일반적인 역할은 서로 열린 connection을 통해 클라이언트와 서버의 트래픽을 전달하는데 있습니다.
이러한 proxy 모드는 세 종류가 있습니다.
1. 유저스페이스 프록시 모드
각 서비스는 로컬 노드에서 포트(임의로 선택됨)를 연다.
kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의 SessionAffinity 설정을 고려한다.
2. iptables 프록시 모드 (default 모드)
각 서비스에 대해, 서비스의 clusterIP 및 port에 대한 트래픽을 캡처하고
해당 트래픽을 서비스의 백엔드 세트 중 하나로 리다이렉트(redirect)하는 iptables 규칙을 설치합니다.
각 엔드포인트 오브젝트에 대해, (복제된) 백엔드 파드를 선택하는 iptables 규칙입니다.
iptables 모드의 kube-proxy는 임의의 (복제된) 백엔드 파드를 선택한다.
이 규칙을 사용하면 유저 스페이스 프록시 모드보다 시스템의 오버헤드가 줄어듭니다.
유저스페이스와 커널 스페이스 사이를 전환할 필요없이 리눅스 넷필터(netfilter)가 트래픽을 처리하기 때문입니다.
이 접근 방식은 더 신뢰할 수 있기도 합니다. 그래서 default인가?
임의의 파드로 선택을 해야하는데 iptables 프록시 모드는
준비성 컨테이너 프로브(kubelet에 의해 주기적으로 수행되는 진단)를 사용해서 복제된 파드들이 제대로 동작하는지 확인 할 수 있습니다. 그렇기 때문에 iptables 모드의 kube-proxy는 정상으로 테스트된 복제된 백엔드 파드만 볼 수 있는것이죠.
한 마디로 걸러서 정상적인 파드들만 보여주므로 실패할 확률이 적고, 신뢰할 수 있다 라는 말
kubelet = 각 노드에서 실행되는 에이전트
에이전트 = 복잡한 동적인 환경에서 목표를 달성하려고 시도하는 시스템
한 마디로 kubelet은 각 노드에서 실행되는 여러 목표를 달성하려고 지속적으로 동작하는 시스템!
3. IPVS 프록시 모드
마지막으로 IPVS 프록시 모드입니다.
iptables와 비슷하게 리눅스 넷필터(netfilter)가 트래픽을 처리하는 방식을 기반으로 하지만,
해시 테이블을 기본 데이터 구조로 사용하고 커널 스페이스에서 동작을 하기 때문에
iptables 모드의 kube-proxy보다 더욱 지연 시간이 짧은 트래픽을 리다이렉션하고,
성능이 훨씬 상향되었습니다.
이 프록시 모델에서 클라이언트가 쿠버네티스 또는 서비스 또는 파드에 대해 알지 못하는 경우 서비스의 IP:포트로 향하는 트래픽은 적절한 백엔드로 프록시됩니다.
이 세 가지의 프록시 모드들에 대해서 특정 클라이언트의 연결이 매번 동일한 파드로 전달되도록 하려면,
service.spec.sessionAffinity를 "ClientIP"로 설정하여 클라이언트의 IP 주소를 기반으로 세션 어피니티(Affinity)를 선택할 수 있습니다. (기본값은 "None" 이기 때문에 무작위로 연결이 파드에게 전달이 됩니다.)
또한 service.spec.sessionAffinityConfig.clientIP.timeoutSeconds를 적절히 설정하여 최대 세션 고정 시간을 설정할 수도 있습니다. (기본값은 10800으로, 3시간)
복제 된 pod의 재실행
podSpec에서 pod의 재시작 정책을 명시할 수 있습니다.
podSpec의 restartPolicy필드를 조절하면 되는데 default값은 Always로 항상 재실행하게 되어있습니다.
실패 시(OnFailure), 절대 안 함(Never)등의 값으로 설정이 가능합니다.
restartPolicy는 파드 내의 모든 컨테이너들에게 내리는 설정입니다.
그러면 pod자체의 재실행 정책은 어디서 해주는 걸까요?
파드의 재실행 정책은 deployment에서 해줍니다.
쿠버네티스 서비스를 운용할 때 지속적으로 서비스를 제공해주기 위해
업데이트를 할 때에도 지속적으로 서비스가 제공되는 것처럼 해주기 위해
롤링 업데이트라는 새로운 파드로 대체하는 전략을 제공합니다.
deployment의 .spec.strategy 는 이전 파드를 새로운 파드로 대체하는 전략을 명시할수 있습니다.
.spec.strategy.type 은 "재생성" 또는 "롤링업데이트"가 될 수 있습니다. "롤링업데이트"가 기본값입니다.
재생성(Recreate)
재생성(Recreate)으로 설정해주게 되면 기존의 파드는 새 파드가 생성되기 전에 죽습니다.
이렇게 하면 업그레이드를 생성하기 전에 파드 종료를 보장할 수 있습니다.
롤링업데이트(Rolling Update)
롤링업데이트는 동시에 삭제할 수 있는 파드의 개수를 조정해줌으로써 서비스가 지속적으로
제공되는 것 처럼 해주고, 순차적으로 업데이트를 해주는 방식입니다.
최대 불가(Max Unavailable), 최대 서지(Max Surge)를 명시해서 롤링 업데이트 프로세스를 제어할 수 있습니다.
두 개의 필드 전부 의도 된 숫자 (ex : 1, 2, 3) 혹은 비율 (ex : 10%, 25% )로 표현될 수 있습니다.
Max Unavailable 필드는 롤링 업데이트 중 동시에 삭제할 수 있는 파드의 최대 개수를 나타내는데,
기본값은 25%로 동시에 삭제할 수 있는 파드가 만약에 replicas가 4 라면,
동시에 최대 하나의 pod를 삭제할 수 있는것입니다.
Max Surge 필드는 롤링 업데이트 중 동시에 생성하는 파드 개수입니다.
기본값은 동일하게 25%로 replicas가 4 라면 하나의 pod가 동시에 생성이 됩니다.
그러면 무조건 높게하는게 좋은것 아닌가? 생각할 수 있지만 그 만큼 필요한 시스템 자원이 급증할 수 있기 때문에
자신의 시스템의 총 자원량을 잘 파악해서 설정을 해주어야 합니다.
참고
https://blog.2dal.com/2018/04/30/kubernetes-02-replicaset/
Kubernetes 02 - ReplicaSet | asbubam's blog on 2dal.com
지난 글 Kubernetes 01 – Pod 에서는 K8s(Kubernetes)의 가장 작은 배포 단위인 Pod에 대해서 설명했었다. 오늘은 ReplicaSet에 대해서 이야기 해보려고 한다. 지난 글에서 라고 설명했었는데, ReplicaSet은 Pod (O
blog.2dal.com
https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/#%EC%A0%84%EB%9E%B5
디플로이먼트
디플로이먼트 는 파드와 레플리카셋에 대한 선언적 업데이트를 제공한다. 디플로이먼트에서 의도하는 상태 를 설명하고, 디플로이먼트 컨트롤러(Controller)API 서버를 통해 클러스터의 공유된 상�
kubernetes.io
https://kkimsangheon.github.io/2019/06/15/kube17/
14. 쿠버네티스 배포 전략(롤링업데이트, 블루그린)
어플리케이션을 컨테이너로 배포하는 시대에 들어오면서 배포 전략에도 변화가 생겼다. 컨테이너의 장점을 살려 작업을 자동화하고 서비스 무중단을 어떻게 유지해야 할지를 고민한다. 롤링 ��
kkimsangheon.github.io
https://kubernetes.io/ko/docs/concepts/services-networking/service/
서비스
쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록하는 확장 API이다. 쿠버�
kubernetes.io
파드 라이프사이클
이 페이지는 파드의 라이프사이클을 설명한다. 파드의 단계(phase) 파드의 status 필드는 phase 필드를 포함하는 PodStatus 오브젝트로 정의된다. 파드의 phase는 파드가 라이프사이클 중 어느 단계에 해�
kubernetes.io
'Kubernetes & Docker > 궁금한 것' 카테고리의 다른 글
| 쿠버네티스 podSpec의 호스트(host)에 대해서 (0) | 2020.07.17 |
|---|---|
| 쿠버네티스 네트워킹(networking)과 포트 포워딩(port forwarding)에 대해서 (1) | 2020.07.17 |
| 쿠버네티스 스케줄러 : 노드(node)에 파드(pod)의 배치 방법 (2) | 2020.07.17 |
| 쿠버네티스 "kubectl get all" 명령어에 나오는 모든 것들에 대해서 (0) | 2020.07.17 |
| 쿠버네티스 YAML 파일 작성 시 실행 순서에 대해서 (0) | 2020.07.17 |