Kubernetes

개요 쿠버네티스 1.28 버전부터 도입된 sidecar container에 대해 알아본다. 1.28 버전 이전의 sidecar 패턴 Sidecar 패턴은 서비스 메시, metric 수집, secret 가져오기 등에서 많이 쓰여왔다. 하지만 사이드카 컨테이너를 구현하기는 쉽지 않았다. 1.28버전 이전까지는 컨테이너가 사이드카 컨테이너임을 쿠버네티스에게 알려줄 방법이 없었다. 발생할 수 있는 이슈 이는 사이드카 컨테이너가 메인 컨테이너 종료 전에 종료될 수 있거나, 작업이 실패하더라도 살아있을 수 있다는 의미이다. 따라서 몇가지 문제가 발생했다. Job의 경우 기본 컨테이너가 완료 되었지만 사이드카 컨테이너가 계속 실행되면 pod가 성공적으로 종료 됐는지 올바르게 판단할 수 없다. 사이드카 컨테이너가 너무..

개요 kubernetes의 Autoscaler는 대표적으로 HPA, VPA, CA가 있습니다. 이 페이지에서는 각각의 개념에 대해 정리합니다. HPA(Horizontal Pod Autoscaler) Horizontal Pod Autoscaler는 파드의 리소스를 감시하여, 리소스가 부족한 경우 Controller의 replicas를 증가시켜, 파드의 수를 늘리도록 합니다. 위의 그림 처럼 Pod가 수평적으로 증가하는 것을 Scale Out, 수평적으로 감소하는 것을 Scale In 이라고 합니다. 파드가 증가하였기 때문에 기존의 트래픽이 분산되어 서비스를 더 안정적으로 유지할 수 있게 합니다. HPA는 다음과 같은 경우에 사용이 권장됩니다. 기동이 빠르게 되는 App 파드의 장애가 났을 때 대응하기 위한..

Sidecar 패턴은 서비스 메시, metric 수집, secret 가져오기 등에서 많이 쓰여왔다. 하지만 사이드카 컨테이너를 구현하기는 쉽지 않았다. 1.28버전 이전까지는 컨테이너가 사이드카 컨테이너임을 쿠버네티스에게 알려줄 방법이 없었다. 이는 사이드카 컨테이너가 메인 컨테이너 종료 전에 종료될 수 있거나, 작업이 실패하더라도 살아있을 수 있다는 의미이다. 따라서 몇가지 문제가 발생했다. Job의 경우 기본 컨테이너가 완료 되었지만 사이드카 컨테이너가 계속 실행되면 pod가 성공적으로 종료 됐는지 올바르게 판단할 수 없다. 사이드카 컨테이너가 너무 늦게 시작되어 기본 컨테이너 시작 시 이를 사용할 수 없게 되어 컨테이너가 다시 시작될 때까지 기다려야 한다. Istio 사이드카 컨테이너가 기본 컨테이..

Authentication K8S로 접근하는 방법 X509 Client Certs Cluster에는 접근할 때 필요한 정보(CA crt, Client crt, Client key)가 들어있는 kubeconfig라는 파일이 존재 외부에서 Client Key와 Client crt를 가지고 https로 API Server에 접근이 가능 kubectl은 kubeconfig를 복사하기 때문에 accept-hosts 로 proxy를 개방하면 외부에서 proxy port로 http 접근이 가능 kubectl 외부의 kubectl에서 각 cluster의 kubeconfig 파일을 갖고 있다면 원하는 cluster에 접근이 가능 $ kubectl config user-context context-A kubeconfig ..

Controllers ReplicaSet, Replication Controller ReplicaSet, Replication Controller Template Pod를 재생성할 때, 어떤 Pod를 재생성할 지에 대한 template Template을 update한 후 pod를 재생성하면 업데이트 된 버전으로 재생성함 기존에 연결된 Pod들은 자동으로 변경되지 않음 Template에 Pod dongb.tistory.com Deployment Deployment Update 방식 Recreate 기존 Pod들을 전체 삭제하고 새로운 Pod들을 만든 후 트래픽을 연결하는 방식 특징 삭제 후 새로운 버전의 Pod생성까지 시간만큼 Down Time 발생하는 단점 방법 기존 버전의 Pod를 삭 dongb.tis..

HPA (Horizontal Pod AutoScaler) HPA를 Controller에 연결하면 HPA가 해당 Controller의 Pod 자원 사용량을 체크 임계치 이상 자원을 사용하면 Controller의 replicas를 늘려 Pod을 scale out 시킴 적절한 조건 기동이 빠르게 되는 App에 적용해야 함 Stateless App에 적용해야 함 동작 원리 Node마다 존재하는 Resource Estimator인 cAdvisor가 Container 리소스 사용량을 체크하고 kubelet은 cAdvisor로부터 리소스 정보를 수집 metrics server(Pod)를 설치하면 각 Node의 kubelet으로부터 리소스 사용량을 종합하여 수집 metrics server는 control plane의 ..

사용 예시 Service LoadBalancing Pod마다 Service를 연결한 후 path에 따라 트래픽을 연결시켜 줌 Canary Upgrade 업그레이드 할 Pod에 별도의 Service를 연결시킨 후 설정한 비율의 트래픽을 업그레이드 할 Pod으로 연결시킬 수 있음 Ingress Controller Ingress Controller라고 부르는 Ingress를 구현할 별도의 플러그인을 설치해야 함 대표적인 예시로 Nginx, Kong과 같은 플러그인이 존재 플러인을 설치하면 namespace가 생성되고 그 위에 Ingress 구현체 역할을 하는 Pod이 생성됨 (Deployment가 생성되어 관리 및 생성) 구현체 Pod의 Ingress rule에 따라 Service 및 Pod에 트래픽을 전달시..

Stateless Application VS Stateful Application Stateless Application Stateful Application 역할 단순 복제 각자 역할을 가짐 재생성 같은 서비스의 역할을 하는 앱을 생성 앱 이름 달라도 상관 없음 Down된 앱과 같은 앱을 생성 앱 이름 같아야 함 Volume 하나의 Volume을 공유하여 사용 가능 앱 각자의 Volume을 사용해야 함 네트워크 앱들이 트래픽을 균등하게 나누어 가짐 각 앱의 특징에 맞게 트래픽을 가짐 예시 Apache, Nginx MariaDB, Redis, MongoDB Controller ReplicaSet StatefulSet Service Service Headless Service StatefulSet Cont..

DaemonSet ReplicaSet은 node의 자원 상황에 따라 scheduler가 판단하여 Pod을 배치함 selector 과 template 을 지정해 template으로 각 node에 Pod을 생성하고 selector로 Pod의 label과 연결 특정한 Node에만 배포하고 싶을 때 nodeSelector 로 배포할 node의 라벨을 지정해 선택 배포 가능 hostPort 로 포트를 지정하여 각 Node의 포트가 배포된 Pod과 직접 연결되어 Service의 NodePort와 같이 사용할 수 있음 template 업데이트가 가능하며, 기본 업데이트 방식으로 RollingUpdate를 사용 DaemonSet은 node의 자원 상황에 관계없이 모든 Node에 Pod을 배포해야할 때 사용 사용 예시 ..

Update 방식 Recreate 기존 Pod들을 전체 삭제하고 새로운 Pod들을 만든 후 트래픽을 연결하는 방식 특징 삭제 후 새로운 버전의 Pod생성까지 시간만큼 Down Time 발생하는 단점 방법 기존 버전의 Pod를 삭제하고 새로운 버전의 Pod를 생성 Rolling Update 새로운 Pod을 한번에 설정한 갯수만큼 만들어 연결한 후 기존 Pod을 삭제하는 방식 특징 업데이트 중에 기존 Pod, 새로운 Pod 모두에 트래픽이 요청되기 때문에 구버전과 새버전이 공존하는 시간이 발생하는 단점 한번에 업데이트할 Pod의 갯수만큼 업데이트 하는 순간 자원을 추가 사용 Down Time 없음 방법 먼저 새로운 Pod를 생성한 후 트래픽을 연결 연결 후 기존 Pod을 삭제 기존 Pod 갯수만큼 위 방식 ..