오늘은 istio 설치 방법에 대해 정리를 해보고자 한다.
istio docs를 들어가보면 다양한 설치 방법이 있다. 그리고 현재 재직중인 회사에서는 helm을 기반으로 설치를 했다.
helm을 통해 istiod, istio-base, istio-ingressgateways를 설치하였는데 helm으로 설치하다보니 여러가지 문제가 있다.
- 첫번째로 helm chart 및 values 파일을 관리해줘야 한다. 특히 chart 관리는 여간 귀찮은게 아니다.
- 두번째로 관리해야하는 파일 개수가 많다. istio 컴포넌트를 현재 3개를 사용하고 있는데, 각 환경별 클러스터에 모두 설치하다보니 컴포넌트 개수 * 환경별 클러스터만큼 관리를 해야한다. 이것도 상당히 귀찮다.
세번째는 istio docs에서 운영 환경일 경우에는 Istio operator로 설치하는것을 권장한다.- 네번째로 가장 큰 이유이다. 국내/외 커뮤니티에서 istio의 도움을 얻으려고 하면 대다수가 istio-operator를 기준으로 말하고 있다.
- istio-operator 기준으로 어떻게 해라, 어디에 추가하면 된다. 그래서 최근에 진행한 istio localityLB 기준으로도 istio-operator를 보면 간단하게 yaml 몇줄만 추가하면 된다.
- 하지만 helm으로 배포하다 보니 내가 chart를 수정하거나, 해당 기능이 있는 별도의 kind를 배포하는 번거로움이 있다.
그래서 이번에 istio-operator를 통해서 istio를 설치하는 방법을 정리하려고 한다.
- istio-operator를 쓰면 생각보다 설치가 아주 간단하다.
설치방법
istioctl
먼저 istioctl을 local PC에 설치해야한다. 다른 방법도 있겠지만 이 방법으로 진행하는게 가장 편하다.
Mac 기준으로는 brew 한번이면 설치가 끝난다.
brew install istioctl
istio-operator
istioctl 설치가 선행되어야 한다. Istioctl을 설치했다면 아래와 같이 init만 하면 일사천리로 진행된다.
❯ istioctl operator init
Installing operator controller in namespace: istio-operator using image: docker.io/istio/operator:1.16.1
Operator controller will watch namespaces: istio-system
✔ Istio operator installed
✔ Installation complete
또는 helm으로 배포할 수도 있다.
$ helm install istio-operator manifests/charts/istio-operator \
--set watchedNamespaces="istio-namespace1\,istio-namespace2" \
-n istio-operator
istio-operator가 설치가 되면 아래와 같이 클러스터에 istio-operator 네임스페이스 생기고, pod이 1개 뜬다.
- istio-operator가 하는 일은 아주 간단하다.
- 사용자가 작성한 istio-operator yaml을 해석하고 그에 맞게 서비스를 배포하는거밖에 없다.
여기까지 왔다면 이제 절반 이상 설치가 끝난것이나 다름없다. 남은 것은 이제 yaml 작성법만 알면된다.
istio-operator yaml 작성
istio profile을 default로 사용해서 istiod와 istio-ingressgateway를 배포하는 방법이다.
- 필요에 따라서 istio version(tag), name, resource, hpa, overlays 등등을 변경하면 된다.
- overlays는 k8s patch와 유사하다고 보면 된다.
- istio-operator에서 deployment, hpa, service 등 모든 부분을 제어할 수 없으므로 overlays를 통해 커스텀이 필요한 부분은 사용자가 임의로 작성해야 한다.
아래 코드는 istiod + Istio ingressgateway를 2개 배포하는 코드이다.
아래 캡쳐에서도 알 수 있듯이 istio ingressgateway가 2 세트(auth, public gateway)가 배포되기 때문에 istiod도 2 세트가 배포된다.
- isio docs에서 각 ingressgateway의 독립성을 보장하기 위해 istiod와 세트에 맞춰서 배포하는것을 권장한다.
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
namespace: istio-system
name: istiocontrolplane
spec:
profile: default
# istio docker image
tag: 1.20.0
components:
ingressGateways:
- name: test-auth-gateway
namespace: istio-test
label:
istio: ingressgateway
name: test-auth-gateway
enabled: true
k8s:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 100m
memory: 128Mi
hpaSpec:
minReplicas: 2
# istio ingressgateways에 대해서 AZ 균등 배포를 위함
overlays:
- kind: Deployment
name: test-auth-gateway
patches:
- path: spec.template.spec.topologySpreadConstraints
value:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
name: test-auth-gateway
service:
type: ClusterIP
ports:
- name: status-port
port: 15021
targetPort: 15021
- name: http
port: 80
targetPort: 10080
- name: https
port: 443
targetPort: 10443
serviceAnnotations:
alb.ingress.kubernetes.io/healthcheck-path: /healthz/ready
alb.ingress.kubernetes.io/healthcheck-port: "15021"
- name: test-public-gateway
namespace: istio-test
label:
istio: ingressgateway
name: test-public-gateway
enabled: true
k8s:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 100m
memory: 128Mi
hpaSpec:
minReplicas: 2
# istio ingressgateways에 대해서 AZ 균등 배포를 위함
overlays:
- kind: Deployment
name: test-public-gateway
patches:
- path: spec.template.spec.topologySpreadConstraints
value:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
name: test-public-gateway
service:
type: ClusterIP
ports:
- name: status-port
port: 15021
targetPort: 15021
- name: http
port: 80
targetPort: 10080
- name: https
port: 443
targetPort: 10443
serviceAnnotations:
alb.ingress.kubernetes.io/healthcheck-path: /healthz/ready
alb.ingress.kubernetes.io/healthcheck-port: "15021"
pilot:
enabled: true
k8s:
hpaSpec:
minReplicas: 2
values:
global:
configValidation: true
# istio-proxy sidecar 컨테이너의 리소스
proxy:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 100m
memory: 128Mi
meshConfig:
enableTracing: false
enablePrometheusMerge: false
defaultConfig:
holdApplicationUntilProxyStarts: true
accessLogFile: /dev/stdout
istio operator yaml을 작성했다면 이제, istioctl로 배포를 하면 된다.
istioctl install -f istio_operator_1.28.yaml
istioctl로 배포를 하면 아래와 같은 모습을 볼 수 있다.(pending으로 뜬 모습은 eks 노드 오토스케일링 중이라서..)
istio 사용 방법
정확히는 istio-proxy, sidecar의 사용 방법이다. istio는 기본적으로 sidecar 방식이기 때문에 네임스페이스에 특정 labels을 추가해야 한다. 그리고 해당 네임스페이스에 배포되는 pod에 istio-proxy sidecar 컨테이너가 생기게 된다.
kubectl label namespace istio-test istio-injection=enabled
그리고 이렇게 하면 istio sidecar가 생기게 된다.
istio 사용 참 쉽죠?
이제 나머지는 istio gateway, istio virtualservice 로 도메인을 설정하고, 라우터 설정만 하면 된다.
(이것도 말은 어려워 보이지만, 실제로는 어렵지 않습니다.)
위에서 helm으로 istio를 배포하게 되면 컴포넌트(최소 3개) * 환경별 클러스터만큼 values을 관리해야한다고 했다.
근데 istio-operator를 사용하게 되면 yaml 1개에 istio 컴포넌트들을 모두 정의하게 되므로, 환경별 클러스터 개수만큼의 파일만 관리하면 된다.
즉, 관리해야되는 파일 개수가 현저하게 줄어들게 된다. Devops로서 일하게 되면 많은 Plugin이 있기 때문에 관리해야하는 Values 파일도 점점 많아진다.. 그래서 관리 효율성을 위해서는 최대한 통합을 하고, 파일 개수를 줄이는게 좋다!!
istio-operator를 이용해서 istio 환경을 조성하는분에게 도움이 되었으면 하는 마음과 함께 이만!!
'기술 이모저모 > [Ops] Devops' 카테고리의 다른 글
| [Vault] Vault 백업/복구, 신규 클러스터 마이그레이션 방법 (0) | 2023.12.24 |
|---|---|
| [AWS][istio] istio profile 지정 & client, control plane 버전 (0) | 2023.11.26 |
| [AWS][Istio] Istio proxy_config 엔드포인트 Priority 확인 방법 (0) | 2023.11.05 |
| [AWS][istio] istio LocalityLbSetting, CrossAZ 데이터 비용 절감 (0) | 2023.11.05 |
| [ArgoCD] Application 생성 방법 = ArgoCD를 이용한 배포 (0) | 2023.05.14 |
