23.06.15
DEVOTEE를 활성화 시키면
지금 작성한 커뮤니티 글에 대해 1개의 댓글을 달아줍니다.
버튼을 누르면 글 수정 시 ChatGPT가 작성한 댓글이 수정됩니다.
| 컨텐츠 유형 | 제목 | 저장일 | 삭제 |
|---|
본인인증 로그인에 실패하였습니다.
회원이 아니시거나 본인인증 등록이
완료되지 않은 사용자입니다.
지난 블로그에서 argocd의 강력함을 경험하였습니다.
가시성, 운용관리 편리성, 멀티클러스터 배포 가능 등을 argocd 툴 하나로 확인이 가능하였습니다.
지난 블로그 링크 : AKS로 쿠버네티스 시작하기 : 강력한 ArgoCD로 CD 구성
현재 구축 중인 구성도입니다.
위 그림에서 argocd를 여러 개 설치하는 것을 표시하였습니다.
실무적으로 배포 활동은 편리해야 하면서도 안전성을 확보해야 한다고 생각합니다.
안전성 확보를 위해 argocd를 환경별로 구성할 계획입니다.
argocd설치는 argocd-aop-mgmt, argocd-aop-dev, argocd-aop-stg, argocd-aop-prd 용도로 구분하여 설치할 예정입니다.
이렇게 구성하면 하나의 argocd에서 프로젝트를 나누어서 멀티클러스터용 배포 환경을 구성하는 것보다 복잡하지 않고, 안전하다고 생각합니다.
배포 작업을 하기 전에 배포를 담당하게 될 argocd에 접속을 하면서 먼저 환기를 할 수 있도록 해서 엔지니어가 혹시라도 실수를 할 수 있는 상황을 사전에 막아 보려고 합니다.
즉, 스테이징에서 배포와 테스트 작업이 다 완료된 이후에 상용에 배포를 이어서 작업을 한다고 할 경우,
엔지니어는 argocd-aop-prd로 시작하는 도메인으로 argocd에 먼저 로그인하는 절차를 수행을 해야 상용기에 배포가 가능합니다.
먼저 도메인 할당 업무를 담당하는 동료에게 도메인 할당을 요청합니다. (여기서는 argocd-aop-mgmt.xxx.xxx)
동료가 azure portal에서 바로 작업을 해 줘서 몇 분안에 도메인을 사용할 수 있게 되었습니다. (편리한 cloud 세상!!!)
저희는 다수의 argocd 도메인을 사용할 계획이라 k8s의 ingress오브젝트를 이용해서 구성을 하면 편리하게 데이터를 암호화하여 인터넷 연결을 안전하게 보호하는 TLS 인증서 까지 적용이 가능합니다.
Ingress는 클러스터 안에 있는 서비스에 대한 외부 접근을 관리하는 Kubernetes 리소스입니다.
(k8s의 명칭들은 생각보다 직관적입니다. : 안(in)으로 나아가게(to go) 하는 기능을 수행하는 리소스로 이해가 쉬움)
- 클러스터 외부에서 내부로 접근하는 HTTP(S) 트래픽을 관리하며, 클라이언트 요청을 올바른 서비스로 라우팅하는 역할
- 외부에서 접근 가능한 URL을 관리하고, 효율적으로 로드밸런싱을 수행
아래와 같이 ingress의 장단점을 이해해 보면 좋겠습니다.
장점 | 단점 |
|---|---|
- 단일 IP로 다수의 서비스에 접근 가능 - HTTP(S) 기반의 L7 로드밸런싱 가능 - 동일한 URL 패턴을 사용하는 서비스에 대한 라우팅 가능 - SSL 암호화 기능 제공 - 다양한 인증 및 권한 부여 방식 지원 - 다양한 라우팅 규칙 설정 가능 | - L7 로드 밸런싱을 제공하기 때문에, L4 로드 밸런싱보다 더 복잡 - 다른 네트워크 레이어를 거쳐야 하기 때문에, L4 로드 밸런서보다 성능이 떨어질 수 있음 - 클러스터 외부에서 내부로 접근하는 HTTP(S) 트래픽을 관리하기 때문에, 보안 위협 대상 - 설정은 매우 복잡할 수 있으며, 실수로 인한 잘못된 구성이 발생 가능성 |
Ingress controller로 nginx-ingress, traefik, istio, haproxy 등 다양하게 적용이 가능합니다.
- nginx-ingress, istio가 인기 있는 솔루션으로 알려져 있으며, 현재 프로젝트에서는 손쉽게 적용 가능하고, 가볍고 빠르게 동작하는 nginx-ingress를 적용해 보기로 했습니다.
아래와 같이 nginx-ingress와 istio를 비교해 보았습니다. 성능 측면에서 더 높은 성능이 요구시에는 istio가 권장됩니다.
구분 | nginx-ingress | istio |
|---|---|---|
구성 | 단일 노드에서도 충분히 작동할 수 있는 경량 Ingress 컨트롤러 설정이 간단하며, 배포와 관리가 용이 | 매우 복잡한 기능을 제공하기 때문에, 구성이 매우 복잡하며 배포와 관리가 어려울 수 있음 |
성능 | nginx-ingress도 빠르고 안정적인 L7 로드 밸런싱을 제공 | Envoy 프록시를 기반으로 하고 다양한 기능을 제공하기 때문에, nginx-ingress보다 성능 측면에서 우위 (Envoy는 프록시 서버 기반으로 매우 가볍고 빠르며, 다양한 기능 제공) |
보안 | 기본적인 SSL 인증서 기능을 제공 | mTLS(Mutual Transport Layer Security) 기능을 비롯하여 다양한 보안 기능을 제공 |
기능 | 간단한 로드 밸런싱과 라우팅 기능을 제공 | 트래픽 라우팅, 트래픽 분산, 트래픽 제어, 트래픽 모니터링, 트레이싱, 디버깅 등 다양한 기능을 제공 (istio는 서비스 매쉬를 구현하는 데 사용되는 오픈소스 플랫폼) |
먼저 연결 단계를 기억해 두는 것이 필요하겠습니다.
(연결 단계) 외부LB(azure에서 구성한 LB, aks 클러스터 아님) --> ingress controller --> ingress --> svc(argocd-server)
아래 구성을 하면서 사전에 알아야 할 사항은 ingress controller를 생성하면 azure에서 자동으로 azure LB(클러스터 외부) IP를 ingress controller의 External IP로 할당한다는 점입니다.
따라서, 클라이언트에서는 LB IP로 접속하면 ingress controller로 접근이 되어 이후 부터는 ingress controller의 제어에 들어가게 됩니다.
ingress controller는 ingress 오브젝트로 분기를 하게 하여 원하는 4개의 도메인으로 각각 service를 제공합니다.
Ingress Controller 설치, Ingress yaml작성과 생성, Routing Rule 구성, TLS 구성 순서로 진행하여 k8s ingress를 적용할 수 있습니다.
1단계) Ingress Controller 설치 : Ingress 리소스를 해석하고, 요청을 처리할 수 있는 로드 밸런싱 구성을 생성
2단계) Ingress yaml 작성 : 클러스터 내의 서비스를 외부로 노출, 호스트 및 경로 규칙을 사용하여 요청을 처리할 서비스 구성, TLS 설정을 추가하여, 인증서를 구성
3단계) Ingress yaml내의 routing rule 구성 : 요청을 처리할 서비스를 지정
4단계) Ingress yaml내의 TLS 구성 : https로 보안된 요청을 처리하기 위해 TLS 인증서를 구성(TLS 인증서를 통해, 클라이언트와 서버 간의 통신을 암호화)
5단계) tls 인증서를 위한 secret 생성 : ingress 구성요소로 추가되어 ingress 생성시 반영하기 위한 secret 생성
6단계) Ingress 생성 : 작성된 ingress yaml 파일을 k8s클러스터에 반영(apply)
아래의 명령어로 서비스별 라우팅 기능을 수행할 수 있게 해 주는 인그레스를 설치하겠습니다.
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/cloud/deploy.yamlingress 생성을 위해 yaml 파일 작성을 합니다.
name, namespace, annotations, rules.host, service.name 이 ingress오브젝트 구성을 성공하는 데 중요한 요소입니다.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-argocd-aop-mgmt
namespace: argocd-mgmt
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/ssl-passthrough: "true"
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
rules:
- host: argocd-aop-mgmt.xxx.xxx # 도메인명 일부 내용 비식별 처리
http:
paths:
- backend:
service:
name: argocd-server
port:
name: https
path: /
pathType: Prefix
tls:
- hosts:
- argocd-aop-mgmt.xxx.xxx # 도메인명 일부 내용 비식별 처리
secretName: tls-aop-mgmt-xxxxtls 구성 내용에 대해서는 아래에서 추가 설명을 하겠습니다.
rules:
- host: argocd-aop-mgmt.xxx.xxx # 비식별 처리
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: argocd-server
port:
name: https tls:
- hosts:
- argocd-aop-mgmt.xxx.xxx
secretName: tls-aop-mgmt-xxxx아래의 명령어로 인증서를 secret 오브젝트(tls 유형)로 생성합니다. secret은 ingress yaml에 요소로 추가되어 ingress 생성시 반영이 됩니다.
$ kubectl create secret tls tls-aop-mgmt-xxx --cert <cert파일> --key <key파일> -n argocd-mgmt위에서 최종 완료된 yaml 파일을 kubectl apply 명령을 수행하여 ingress를 생성합니다.
$ kubectl apply -f <ingress yaml 파일>
# 여기서는 아래와 같습니다.
$ kubectl apply -f ingress-aop-mgmt.yaml구성 결과를 아래와 같이 확인해 보면 이해가 더 쉬울 것 같습니다.
구성한 ingress controller의 LB IP가 서비스의 진입점(External IP : 20.196.xx.xx)으로 ingress controller는 ingress의 rule을 통해서 client의 타겟 host로 라우팅을 수행합니다.
여기서는 4개의 도메인 모두를 외부IP인 ingress controller 로 매핑을 한 구성입니다.
해당 도메인 접속 시 ingress controller의 External IP로 접속을 시도하게 되면 ingress controller가 ingress rule에 따라
각 도메인 호스트에 해당하는 service(argocd-server)로 라우팅하게 됩니다.
도메인명으로 접속이 가능합니다. ingress controller가 외부 클라이언트의 요청에 대해 내부인 argocd-server(ClusterIP)로 정상 라우팅을 수행하였습니다.
TLS 인증서 적용도 성공하여 클라이언트인 브라우저와 argocd서비스간에 암호화된 통신이 가능하게 되었습니다.
argocd툴이 도메인으로 접속 가능해서 편리하지만 누구나 접속 가능하지 않도록 보안성을 확보할 필요가 있습니다.
AKS의 NSG(network security grooup) 기능으로 접속 네트워크나 IP를 제한할 수 있습니다.
보안성 조치1) AKS 네트워킹의 보안 기능을 통한 접속가능 대상 네트워크나 IP 한정
보안성 조치 2) NSG를 통한 접속 가능한 IP나 네트워크 한정
argocd 툴에 도메인명으로 편리하게 접속을 할 수 있도록 구성을 완료하였습니다.
구성과정에서 ingress controller 가 ingress의 rule을 통해서 라우팅을 제어하는 동작에 대한 이해가 공식문서로 이해할 때 어려움이 있었으나, 경험있는 동료의 도움으로 도식화된 그림 형태로 이해할 수 있었습니다. 핵심은 ingress controller가 각 타겟host별로의 라우팅을 수행할 수 있다는 개념이었습니다. 처음에는 ingress내의 path개념으로 타겟 도메인을 분기해 보려고 했으나 path별 분기시에는 host를 다르게 가져갈 수 없다는 것을 구성 중에 알게 되었습니다.
현재까지 구성한 클러스터를 기반으로 간단한 애플리케이션을 배포해 보도록 하겠습니다.
DEVOTEE를 활성화 시키면
지금 작성한 댓글에 AI가 댓글을 달아줍니다.