istio 생성 및 사이드카 인젝션

k3s를 사용하는데 istio랑 호환이 안돼서 삽질하다 eks 환경 넘어왔는데 이번에는 버전문제때문에 삽질했다,,, 버전 문제,,,,,

 

우선 istio 다운로드 방식은 istioctl을 이용해서 환경 구성을 할 수 도있지만 istio-operator를 사용하는게 훨씬 편해 

istio-operator로 다운로드 받았다.

 

우선 다운로드 순서는 아래 내용참고 하면 좋다

https://istio.io/latest/docs/setup/getting-started/

 

 istio 다운로드
 curl -L https://istio.io/downloadIstio | sh -
 
 경로 이동
 cd istio-1.15.3
 
 환경 변수 설정해서 시작
 export PATH=$PWD/bin:$PATH

istioctl operator init을 통해 istioctl operator 설치 확인 가능 및 ns에 istioctl-operator가 생성 된것을 확인 가능하다

 

다음으로 설치 된 istioctl operator를 사용하여 istio profile: demo 모드를 생성 하고 배포

 

참고로 istio profile 모드들은 다음과 같이 차이가 있다

 

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
  name: example-istiocontrolplane
spec:
  profile: demo

istio ingress와 egress 및 istio 자체가 생성된것을 확인 가능 하다

여기서  ingress와 egress에 주어지는 컨테이너에 용량 및 여러 가지를 제어 가능하다

아래 처럼 ingressgateway에 limit과 request를 설정해보고 재배포한다

수정 후 ingress gateway 파드를 확인 해보면 다음 설정했던 내용들이 추가된것을 확인 가능하다.

 

 

특이한게 istio를 생성하면 아래처럼 classic 유형의 lb가 생긴다.

아래 참조글을 읽으면 istio를 생성하면 기본적으로 clb가 생성되는거 같다

하지만 clb자체가 지원해주는 기능도 적고 aws에서도 지원이 끊긴서비스 여서 alb/nlb로 대체 해줘야한다고 한다

 

그렇기 때문에 만약 alb 또는 nlb를 생성 할때 istio 자체를 생성할 때 설정 해줘야한다.

 

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
  name: istiocontrolplane
spec:
  profile: default
  components:
    egressGateways:
    - name: istio-egressgateway
      enabled: true
      k8s:
        hpaSpec:
          minReplicas: 2
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        hpaSpec:
          minReplicas: 2
        service:
          type: NodePort # ingress gateway 의 NodePort 사용
        serviceAnnotations:  # Health check 관련 정보
          alb.ingress.kubernetes.io/healthcheck-path: /healthz/ready
          alb.ingress.kubernetes.io/healthcheck-port: "30279" # 위에서 얻은 port number를 사용
    pilot:
      enabled: true
      k8s:
        hpaSpec:
          minReplicas: 2
  meshConfig:
    enableTracing: true
    defaultConfig:
      holdApplicationUntilProxyStarts: true
    accessLogFile: /dev/stdout
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY

해당 내용으로 재배포하면 clb는 사라진것을 확인 가능 이제 ingress를 사용하면 alb가 생성되는것을 확인할 수 있다.

 

(이 부분은 한번 더 해보는게 좋을듯!)

 

https://dev.to/airoasis/eks-eseo-istio-wa-application-load-balancer-yeongyeol-2k2j

AWS EKS 에서 Istio 와 Application Load Balancer 연결

 

 

사이트카 인젝션은 2가지 있다

 

1. 명령어를 통해 인젝션

2. 네임스페이스를 라벨링해서 특정 네임스페이스에 라벨링

 

1.  명령어를 통해 인젝션

야믈파일이 배포되어진 상태에서  istioctl kube-inject -f test-istio.yaml | k apply -f -  사용하여 istio injection

 

생성했던 파드 하나는 사라지고 2개의 컨테이너가 포함된 파드가 생성되어지고 있다.

describe 파드 정보를 확인 해보면 내부의 istio가 생성 된것을 확인 가능하다

 

2. 네임스페이스를 라벨링해서 특정 네임스페이스에 라벨링

default 네임스페이스의 istio-injection=enabled 라벨링을 붙혀 istio 설치

  k label ns default istio-injection=enabled --

 

설정 후 ns 가 default인 디플로이먼트를 생성해보면 아무 명령어 안했는데 파드 2개가있고 istio가 설치된것을 확인 가능

위와 똑같은 events가 발생한것을 확인 가능

k logs 파드이름 -c istio-proxy로 로그 확인해도 작동되는것 확인

\

하지만 네임스페이스를 통쨰로 라벨링하면 사이드카를 제외하고 싶을때도 있다 이럴경우 아래와 같이 야믈파일에 설정하면 된다.

spec.template.labels.sidecar.istio.io/inject: "false" 에 삽입

이렇게 ns가 라벨링 되어있어도 sidecar.istio.io/inject: "false" 를 통해 사이드카 미설치 가능

(참고로 라벨 뺴는건 k label ns default istio-injection- 로 가능)