[Amazon EKS STUDY] #2주차 (이론) AWS VPC CNI (2)

2. Ingress

• 클러스터 내부의 서비스(ClusterIP, NodePort, Loadbalacner)를 외부로 노출(HTTP/HTTPS) 
• Web Proxy 역할
• AWS LB Controller + Ingress (ALB) IP 모드 동작 with AWS VPC CNI

 

3. ExternalDNS

• K8S 서비스/인그레스 생성 시 도메인을 설정하면, AWS(Route53), Azure(DNS), GCP(Cloud DNS)에 A 레코드(TXT 레코드) 자동 생성/삭제
• External DNS Controller 권한 주는 법: Node IAM Role, Static credentials, IRSA
• Ingres, Deployment가 생성되면 ExternalDNS Controller가 CSP Route53에 레코드 등록 진행

참조: https://gasidaseo.notion.site/K8S-Ingress-b38c1cbed5f9481bafa4d5315999e66a

 

4. Istio

4.1 서비스 매시(Service Mesh)

구글, IBM, Lyft 등 여러 회사들이 공동으로 개발한 오픈 소스 

• 등장 배경: MSA 환경의 시스템 전체 모니터링 어려움, 운영 시 시스템 문제 발생할 때 원인과 병목 구간 찾기 어려움
• 개념: 마이크로서비스 간 매시 형태의 통신이나 그 경로를 제어
  ex) Istio, Linkerd, AWS App Mesh
• 기본 동작: 파드 간 통신 경로에 프록시(Proxy)를 두고 트래픽 모니터링이나 트래픽 제어
                  → 기존 Application 코드 수정 없이 구성 가능
• 트래픽 모니터링: 요청의 '에러율, Latency, Connection 수, Request 수' 등 Metric 모니터링, 특정 서비스 간 필터링
                  → 원인 파악 용이 !
• 트래픽 제어: 
             ㆍ트래픽 시프팅(Traffic Shifting)
                            특정 단말/사용자는 신규앱에 전달하여 단계적으로 적용하는 Canary 배포 가능
                            ex) 99% 기존앱 + 1% 신규앱
             ㆍ서킷 브레이커(Circuit Breaker): 
                            목적지 마이크로서비스에 문제가 있을 시 접속 차단 및 출발지 마이크로서비스에 요청 에러 반환
                            시스템 전체 장애 예방
             ㆍ폴트 인젝션(Fault Injection):
                            의도적으로 요청 지연 및 실패 구현
             ㆍ속도 제한(Rate Limit): 
                            요청 개수 제한

 

4.2 Istio 구성 요소와 envoy

4.2.1 Istio service mesh

data plane과 control plane으로 구성됩니다.

 

Data Plane

• intelligent proxies (Envoy)들로 구성됨 (sidecar 형태로 배포됨)

Envoy (proxies)

• 마이크로서비스 간 중계 및 제어
• 트래픽 제어: HTTP, gRPC, WebSocket, TCP 라우팅- 보안 및 인가: 구성 API를 통해 보안 정책 강화, 접근 제어 강화 등
• 메시 트래픽에 대한 사용자 지정 정책 시행
• 네트워크 탄력성: 재시도, 페일오버, 서킷브레이저, 폴인젝션 설정
• 모든 Mesh Traffic을 수집 및 보고
• 빌트인 기능   
  • 로드밸런싱   
  • 서킷 브레이커   
  • 단계적 롤아웃
  • 헬스체크
  • TLS 종료
  • 동적 서비스 복원

 

Istiod

• Istiod는 서비스 검색, 구성과 인증 관리을 제공함
• Pilot
  Data plane과 통신하면서 라우팅 규칙 동기화 및 사이드카로 전파
• Gally
  Istio와 K8S 연동, Endpoint 갱신 등
  Envoy API를 준수하는 모든 sidecar가 사용할 수 있는 표준 형식으로 변경
• Citadel
  연결 암호화 및 인증서 관리 등
• Envoy proxy
  C++
• Istio의 트래픽 관리 API를 사용하면 Istiod가 Envoy 구성을 세분화하여 서비스 메시의 트래픽을 보다 세부적 제어 가능합니다.
• Istiod 보안은 내장된 ID 및 자격 증명을 통해 강력한 서비스 간 및 end user 인증을 지원합니다.
• 인증기관(CA) 역할을 하며 Data Plane에서 안전한 mTLS 통신을 허용하는 인증서 생성합니다.

 

 

4.2.2 Istio 구성요소와 envoy: 컨트롤 플레인(istiod),  데이터 플레인(istio-proxy > envoy)

 

 

 

kube-ops-view

# 설치
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl patch svc -n kube-system kube-ops-view -p '{"spec":{"type":"LoadBalancer"}}'
kubectl annotate service kube-ops-view -n kube-system "external-dns.alpha.kubernetes.io/hostname=kubeopsview.$MyDomain"

# 접속 주소 확인 : 각각 1배, 1.5배, 3배 크기
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080"
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080/#scale=1.5"
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080/#scale=3.0"

# nginx 파드 배포
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/2/nginx-dp.yaml
kubectl apply -f nginx-dp.yaml
kubectl scale deployment nginx-deployment --replicas 15
kubectl scale deployment nginx-deployment --replicas 40
kubectl delete -f nginx-dp.yaml