DevOps

이전 포스팅에서는 쿠버네티스 클러스터 내부 통신을 담당하는 Service 오브젝트의 동작원리에 대해 깊게 살펴봤습니다. 클라이언트가 서비스를 이용하기 위해서는 결국 클러스터 외부에서 접속을 시도해야 합니다. 이때 클러스터의 가장 앞단에서 외부 트래픽을 보안/수정 처리를 한 후 내부 Service로 라우팅하는 역할을 하는 컴포넌트가 존재하는데, 이를 인그레스 컨트롤러라고 합니다. 이번 포스팅에서는 인그레스와 관련된 요소들이 어떤게 있는지 살펴보고, 외부 트래픽이 어떤 흐름으로 클러스터의 내부 파드까지 전달이 되는지 분석해보겠습니다. 인그레스는 클러스터에 유입되는 모든 트래픽을 관리하는 만큼 인그레스 컨트롤러(Nginx) 자체가 제공하는 기능에 대한 깊은 이해가 필요합니다. 이 부분은 실무를 진행하면서 경험..

최근 서비스 운영 환경은 쿠버네티스 클러스터 내에 마이크로서비스를 배포하는 방식이 메인스트림이 되었다고 생각합니다. 그만큼 사용자의 요청이 인그레스를 통해 들어오면 클러스터 내에서 여러 서비스 간 네트워크 통신을 거쳐 응답이 반환되는 구조입니다. 보통 클러스터로 진입하기 이전까지는 HTTPS 암호화 통신이 보장되지만 클러스터 내부로 들어오면 평문 데이터 통신을 하게 됩니다. 만약 악의적인 사용자가 인그레스 게이트웨이를 거치지 않고 클러스터 내부로 접근해서 트래픽을 캡쳐한다면 중요한 데이터가 외부로 노출될 위험이 있습니다. 따라서 쿠버네티스 클러스터 내에서도 데이터를 암호화하고 인증받은 클라이언트만 API를 호출할 수 있도록 해야합니다. 쿠버네티스 클러스터 내의 트래픽 통제를 위해 서비스 메시라는 아키텍쳐..

쿠버네티스를 잘 사용하기 위해서는 방대한 지식을 습득해야 합니다. 그 중 어플리케이션 개발자가 잘 알아야 하는 분야가 있을 것이고, 반대로 인프라 담당자가 잘 이해해야 하는 분야가 있을 것입니다. 저는 개발자로서 쿠버네티스 워크로드의 최소 단위이자, 우리가 만든 어플리케이션이 동작하는 환경인 파드에 대한 깊은 이해가 중요하다고 생각합니다. 이번 포스팅에서는 파드와 내부 컨테이너의 라이프사이클 및 리소스 관리에 대해 알아보도록 하겠습니다.컨테이너의 라이프사이클필자는 처음 쿠버네티스에 대해 학습할때 파드와 컨테이너가 일대일로 매핑되는 개념이라 생각했다. 하지만 파드는 한개 이상의 컨테이너로 구성된 단위라는걸 알게 됐다. 파드의 라이프사이클을 이해하기 위해서는 내부의 컨테이너의 라이프사이클에 대해 학습하는 과..

쿠버네티스를 학습하면서 네트워크에 대한 부분이 어렵게 다가왔습니다. 특히 Spring Cloud 기반의 MSA 어플리케이션을 쿠버네티스 환경에 배포할때는 eureka service discovery의 역할을 쿠버네티스의 Service가 대신해줄 수 있다는걸 알게되면서 이 컴포넌트에 대한 깊은 이해가 필요하다고 생각했습니다.Service 오브젝트 사용 이유먼저 Service라는 오브젝트를 왜 사용해야 하는지 생각해보자. 만약 클라이언트 파드와 서버 파드가 있을때 서버 파드의 IP 주소를 알고 있다면 우리는 직접 통신을 연결할 수 있다. 만약 같은 노드 내에 두 파드가 존재한다면 cbr0라는 브릿지 네트워크를 통해 바로 통신을 할 수 있다. 다른 노드에 위치한다고 해도 노드 간 통신에 사용되는 라우팅 테이블..