한성이 DevOps 블로그

파드에 Requests/Limits 설정에 따라 자동으로 QoS Class 값이 설정되게 되어 있습니다. QoS Class란 kubernetes가 컨테이너에 oom score를 설정할때 사용됩니다. oom score는 OOM Killer에 의해 프로세스를 정지시킬 때 우선순위 값으로 -1,000(최고 순위) ~ 1,000(최저순위) 범위에서 설정합니다. 따라서, kubernetes의 리소스가 부족할 때 즉, 노드에 리소스가 부족할때 QoS에 따라 어떤 파드의 컨테이너를 kill 할지 결정합니다. □ BestEffort pod의 어떤 container내에도 Request와 Limit이 미설정 되어있는 경우입니다. 이럴경우 limit을 설정하지 않았기 때문에 노드에 유후 자원이 존재한다면 제한 없이 모든 자..

Kubernetes에는 세가지 헬스 체크 방법이 있습니다. Liveness Probe, Readiness Probe, Startup Probe 라는 세 가지 헬스 체크 방법이 있습니다. 모두 역할이 다를 뿐 설정 가능한 내용은 똑같고 spec.containers에 설정하게 됩니다. Probe 종류 역할 실패 시 동작 Liveness Probe 파드 내부의 컨테이너가 정상 동작중인지 확인 컨테이너 재기동 Readiness Probe 파드가 요청을 받아들일 수 있는지 확인 트래픽 차단 (파드를 재기동 하지 않음) Startup Probe 파드의 첫 번째 기동이 완료되었는지 확인 다른 Probe 실행을 시작하지 않음 □ Liveness Probe 파드 내부의 컨테이너가 정상적으로 동작 중인지 확인하기 위한 헬..

MSA 아키텍처를 많이 지향하고 있는 추세인데, 해당 트렌드에 맞춰서 무중단으로 안전하게 배포할 수 있는 전략이 많이 나오고 있습니다. 해당 포스팅에서 Rolling 배포 및 카나리 블루/그린 배포에 대해서 설명하고 kubernetes deployment에 업데이트 전략에 대해 다뤄보겠습니다. 보통 Rolling 업데이트, 카나리, 블루/그린 배포는 무중단으로 배포할 수 있는 기법입니다. □ Rolling 배포 Rolling 배포의 정의는 사용중인 서비스 내에서 새 버전을 점진적(순차적)으로 교체하는 것을 말합니다. 관리가 편하지만, 배포 중 하나의 서비스 수가 감소되므로 서버 처리 용량을 미리 고려해야 합니다. Rolling 배포는 사용 중인 Pod 내에서 새 버전으로 점진적으로 교체하는 것으로 무중단..

해당 포스팅은 "쿠버네티스 완벽 가이드" 책을 많이 참고해서 작성되었습니다. Kubernetes의 스케줄링에는 필터링 과정과 스코어링 과정이 있습니다. * 필터링(단정)에서는 스케줄링하는 파드가 할당 가능한 노드를 계산합니다. 예를들어 파드를 스케줄링하는 데 충분한 리소스가 있는지 또는 필수 조건으로 지정한 레이블을 가진 노드인지 등을 체크합니다. * 스코어링(우선순위)에는는 필터링된 후 노드 목록에 순위를 매겨 가장 적합한 노드를 계산합니다. 우선순위 조건으로 지정한 레이블을 가진 노드를 우선적으로 처리합니다. 따라서, 필터링이나 스코어링을 지정하지 않아도 Kubernetes가 자동으로 계산되어 스케줄링에 사용되는게 가장 큰 장점입니다. Kubernetes 스케줄링 분류는 다음과 같습니다. Kubern..

istio gateway는 클러스터 외부에서 발생하는 트래픽으로부터 클러스터에 대한 액세스를 보호하고 제어하는 역할을 합니다. 또한 istio gateway는 로드 밸런싱 및 가상 호스트 라우팅의 역할을 담당합니다. 아래 그림처럼 client 1이 svc-a.foo.com으로 외부에서 요청이 들어오면 맨 먼저 istio gateway에 도달하게 되고 미리 정의해둔 gateway에 svc-A -> 1.1.1.1/2.2.2.2 처럼 hostname과 path의 규칙을 따라 svc-A로 트래픽을 전달하게 됩니다. 제가 생각하는 흐름은 간단하게 client -> istio-ingressgateway -> gateway -> virtual service -> svc -> pod 처음 istio를 설치하면 isti..

Gitlab의 CI/CD 파이프라인은 Jobs와 Stages로 구성됩니다. Jobs는 수행할 작업을 정의하며 Stages는 jobs를 실행할 시기를 정의합니다. Stage가 성공적으로 끝난다면 다음 Stage로 넘어가게 됩니다. 금번 포스팅에서는 .gitlab-ci.yml 파일을 활용하여 Kubernetes에 Application을 배포하는 방법을 공유하고자 합니다. CD는 Gitlab-Runner를 활용합니다. 간단한 프로세스는 다음과 같습니다. gitlab pipeline을 돌릴때는 Triggering pipelines API를 사용하여 돌려보겠습니다. □ kubectl 명령어를 쓸수있는 서버 즉, kubernetes api 서버와 통신할수있는 서버에 Gitlab-Runner를 설치 □ gitlab-..

□ Service Mesh 란? 서비스 메시는 기존의 모놀리식 워크로드를 현대화하고 서비스 간의 통신을 제어하고 관리할 수 있도록 하는 데 특화된 마이크로서비스를 위한 인프라 계층입니다. 기존의 서비스 아키텍처의 호출이 직접 호출 방식이었다면, 서비스 메시에서의 호출은 자체 인프라 계층의 Proxy를 통해 이뤄지게 됩니다. 서비스 메시를 구성하는 개별 proxy는 서비스 내부가 아니라 각 서비스와 함께 실행되므로 'sidecar'라고도 합니다. 각 서비스에서 분리된 이러한 sidecar proxy들이 모여서 Mesh Network를 형성합니다. □ Service Mesh 왜 필요한가? 컨테이너 오케스트레이터 지금 많이 쓰고 있는 Kubernetes가 이미 존재합니다. 하지만 또 다른 인프라스트럭처 계층이..

먼저 해당 기능을 사용하게 된 이유는 master node에 pod가 스케줄링 되지 않게 NodeAffinity 옵션을 사용하였는데도 계속 master node에 pod가 스케줄링 되는 상황을 직면하였습니다. 사용한 NodeAffinity 속성은 다음과 같습니다. 아래의 속성에 관련된 Affinity 속성을 간단하게 정리해보았습니다. □ Affinity 라벨링 기반의 스케줄링은 단순히 키 값이 같은지만을 비교해서 노드를 할당하기 때문에 활용 방법이 비교적 제한되어 있습니다. nodeSelector 대비 더 유연한 표현식으로 Node를 지정하고 싶을때 affinity나 inter pod affinity를 이용하면 됩니다. 위의 Taints가 Pod가 배포되지 못하도록 하는 정책이라면, affinity는 P..

이번 포스팅은 Kubernetes를 운영하면서 어플리케이션에 HTTPS 이슈가 발생하여 해결한 내용을 공유하고자 합니다.. 어떻게 보면 정말 간단하고 Kubernetes networking을 잘 알면 바로 해결할 수 있는 부분이지만, 누군가에게는 도움이 되고자 하는마음에,, 먼저 외부에서 Kubernetes안에서 실행되는 Pod 즉 어플리케이션에 접속하려면 Ingress가 필요합니다. 클라이언트가 HTTP / HTTPS 요청을 Ingress에 보낼 때, 요청한 호스트와 경로에 따라 요청을 전달할 서비스가 결정됩니다. Ingress는 네트워크 스택의 어플리케이션 계층(HTTP Layer Control) 7에서 작동하며 서비스가 할 수 없는 쿠키 기반 세션 어피니티 등과 같은 기능을 제공합니다. hskim...

□ PV(Persistent Volume) 스토리지 볼륨을 마운트 하여 사용할때 Kubernetes에서는 PV라고 명칭하고 있습니다. 관리자가 PV를 생성하면 PVC는 사용자가 볼륨을 사용하기 위해 PV에 요청을 하게 됩니다. □ PVC(PersistentVolumeClaim) 사용자는 Pod를 생성할때 볼륨을 정의하는데 PVC를 지정하여 위에서 관리자가 생성한 PV와 연결하게 됩니다. 위와 같이 Storage를 PV형태로 추가하고 PVC로 Service에 할당해 주는 방식으로 구성됩니다. 또한, PVC는 Namespace Object이기 때문에 Namespace에 디펜던시가 걸리지만 PV는 Cluster Role과 비슷하게 클러스터에서 공용으로 사용할 수 있는 객체입니다. □ PV는 4가지 상태 종류가..