안녕하세요. 번개장터 백엔드 엔지니어 박상조입니다. 이전 포스트까지 따라오셨다면 이제 EKS를 통해 AWS에 k8s가 기본적으로 구성돼 있으실 겁니다. 그렇다면 오늘은 좀 부가적인 것들에 대해 알아볼까 합니다. 먼저 Helm에 대해 알아볼 건데 자세히는 다음에 기회가 되면 포스팅하도록 하고 오늘은 간략하게 소개만 하겠습니다. 오늘 굳이 Helm을 소개해 드리는 이유는 ALB ingress를 Helm으로 설치할 예정이기 때문입니다.
Helm에 대해서는 k8s를 조금 알아보셨다면 아마 한 번쯤 들어보셨을 겁니다. k8s가 컨테이너 환경을 좀 더 쉽고 편리하게 사용할 수 있게 도와준다고 해도 아직 불편함은 있습니다. Helm은 그런 불편함을 조금 해소해주기 위한 k8s의 패키지 매니저입니다.
Helm은 Google과 deis라는 회사가 같이 만든 프로젝트이니 하는 정보는 포스팅의 성격과 맞지 않으니 넘어가겠습니다. Helm은 한마디로 chart를 관리하는 도구입니다. 그렇다면 chart라는 개념을 또 알아봐야 하겠습니다.
여러분이 k8s에 어플리케이션을 한 번 올려보시면 사실 좀 번거로우실 겁니다. 단순히 컨테이너 하나로 운용되는 어플리케이션이라 하더라도 가장 기본적으로 Pod를 정의해야 하고 그 위에 Service를 정의해야 합니다. 하지만 사실 실제 운영환경에선 Deployment도 만들어야 하고 오토스케일링을 위한 hpa나 오늘 다루게 될 ingress 등 많은 오브젝트들을 정의해야 할 것입니다.
chart란 이렇게 어플리케이션이 올라갈 때 어떤 객체들로 구성되어 있는지 구성하는 단위라고 이해하시면 이해가 편하실 겁니다.
Helm은 client-server 구조로 이루어져 있습니다. 사용자가 사용할 CLI인 Hlem이 client이고 k8s에 떠서 어플리케이션을 관리하는 서버는 tiller라고 부릅니다. 사용자가 helm 명령어를 사용해 k8s의 tiller pod와 통신해 어플리케이션을 관리하는 구조입니다.
Mac을 기준으로 설명하겠습니다.
아래 링크에서 파일을 다운로드합니다.
압축을 풀어 helm 파일을 usr/local/bin으로 이동합니다.
아래 명령어를 통해 helm이 제대로 실행되는지 확인합니다.
helm version
아직 tiller가 없어서 Client의 버전이 잘 나오는지만 확인하시면 됩니다.
kubectl create serviceaccount tiller --namespace kube-system
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: tiller-role-binding
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
kubectl apply -f rdbc-config.yaml
helm init --service-account tiller
helm version
이제 설치가 완료되었고 Helm을 사용할 준비가 되었습니다.
k8s에서의 ingress란 간단하게 말하면 k8s의 외부와 내부를 연결해 주는 기능을 하는 오브젝트 입니다. 아마 이렇게만 설명을 하면 Service 오브젝트가 떠오르실 겁니다. 비슷한 일을 할 수 있기 때문입니다. 그렇다면 이 ingress라는 오브젝트는 왜 필요할까요?
다른 오브젝트들과 다르게 ingress는 여러분들이 많이 들어본 이름들이 나옵니다. nginx-ingress, alb-ingress 등 완전히 k8s 자체 오브젝트가 아닙니다. 배경지식이 좀 있으신 분들은 이런 친구들이 무슨 일을 할 수 있을지 감을 잡으셨을 수도 있는데요. 간단하게는 proxy 역할을 하거나 부하 분산을 구성하는 사람이 결정할 수 있게 해줍니다. 이런 것이 Service 오브젝트가 해 줄 수 없는 기능입니다.
ingress도 종류가 많습니다. 그 중 대표적인 것이 nginx-ingress입니다. 아마 이 포스팅을 보고 계신 분들은 nginx를 처음 들으시는 분은 없을 겁니다. 이 nginx를 k8s내에서 프록시 서버로 사용하기 편리하게 만든 게 nginx-ingress라고 생각하시면 이해하기 편하실 겁니다. nginx ingress를 사용해 서버를 구성한다면 아래 그림과 같은 모습이 될 것입니다.
하지만 저희는 AWS의 EKS를 사용하고 있으므로 다른 ingress를 사용할 것입니다.
ALB는 Application Load Balancer의 약자로 아마존에서 제공하는 3가지 로드밸런서 중 하나입니다. 이 ALB를 사용하는 ingress가 바로 ALB ingress입니다. 하지만 조금만 생각해 보면 한가지 문제가 있습니다. 위 그럼에서 보시면 아시겠지만, ingress는 k8s 안에서 부하 분산을 하는 오브젝트 입니다. 하지만 ALB는 k8s 밖에 있죠. 그래서 ALB ingress는 특이한 구조로 되어 있습니다.
글로 설명 하는 것 보다 먼저 그림을 보시면 이해가 빠르실 겁니다.
먼저 위 그림에서 파란색 박스 내부가 k8s의 원래 컨트롤 범위입니다. 하지만 ALB는 k8s의 내부 오브젝트가 아니죠. 그래서 k8s 내부에 ALB를 컨트롤 하는 Pod을 하나 띄우게 됩니다. 이 Pod은 k8s의 API와 통신하게 됩니다. 그래서 ALB를 k8s 내부의 ingress처럼 컨트롤 할 수 있게 해주는 역할을 합니다.
위 그림을 자세히 보시면 Service2는 Node에 직접 연결돼 있고 Service1은 Pod에 바로 연결돼 있는 것을 보실 수 있습니다. 잘 못 그린게 아니고 ALB ingress는 두가지 연결 방법이 있습니다. 하나는 NodePort에 연결하는 방법이고 하나는 Pod의 IP에 직접 연결하는 방법입니다. 또 ALB에 연결하고자 하는 Service는 모두 type이 NodePort여야 합니다. 구조를 보시면 왜 그런지 아실 겁니다. Service의 type에 대해 모르신다면
https://kubernetes.io/docs/concepts/services-networking/service/
위 주소를 참고하시기 바랍니다.
이로써 Helm과 ALB ingress에 대한 기초적인 설명이 끝났습니다. 다음 포스팅에서는 직접 ALB ingress를 구성하는 방법에 대해 알아보도록 하겠습니다.
가입하기
