지식창고

본 문서에서는 Istio를 이용한 Service Mesh 구성에서 Pod sidecar로 실행되는 Envoy에 대한 on-line config 방법에 대해서 공유한다. Istio 로 service mesh가 구성된 상태에서, 특정 pod의 sidecar로 떠있는 container에 접근하여 admin page에 접속하는 명령어는 아래와 같다. kubectl exec -it productpage-v1-6b746f74dc-28fl8 -c istio-proxy -- curl -X POST http://localhost:15000/ 또한, 위의 페이지를 호출하여 istio envoy 의 현재 설정값을 확인하거나 수정이 가능하다. 전체 path 목록은 아래의 명령어를 입력한다. kubectl exec -it pr..

본 문서에서는 application의 sidecar로 떠 있는 istio-envoy container의 TCP Dump를 수집하는 방법에 대해서 설명한다. TCP Dump란? TCP Dump는 주어진 조건식을 만족하는 네트워크 인터페이스를 거치는 패킷들의 헤더들을 출력해주는 프로그램이다. 주로 쓰임은 지정된 상대방 호스트로부터 들어오는 패킷을 체크하는 데 있다. Worker node 확인 아래의 명령어로 내가 확인하고자 하는 pod가 어느 worker node에 떠있는지 확인한다. kubectl get pod -A -o wide Container Process ID 확인 Pod가 떠있는 worker node에 접속하여 아래의 명령어로 sidecar container의 Process ID를 확인한다. 여러..

0. Kubernetes 환경 현재 프로젝트에서 구축한 Kubernetes 환경은 Kubernetes 1.15 버전이고, Node Autoscaling과 Pod Autoscaling 이 적용되어 있다. Worker Node가 AZ별로 이중화되어 있는 환경에서 Pod가 분산 배포되지 않고 한 Node에 몰려있으면, 그리고 그 Node가 Down 상태가 되면 Pod 의 서비스가 같이 Down되게 된다. 이러한 문제점을 피하기 위해 Pod에 Affinity 옵션을 설정하여 Pod을 분산 배포한다. 1. Pod Affinity 파드간 어피니티와 안티-어피니티를 사용하면 노드의 레이블을 기반으로 하지 않고, 노드에서 이미 실행 중인 파드 레이블을 기반으로 파드가 스케줄될 수 있는 노드를 제한할 수 있다. 규칙은 ..

0. VPA(Vertical Pod Autoscaling)이란 Vertical Pod Autoscaling은 Node에 배포된 Pod의 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 Pod에 선언된 Resource Request를 적절하게 조정하거나 적정 Resource Request를 추천한다. Request 조정을 통해 클러스터 리소스 사용률을 개선하고 다른 포드를 위한 CPU 및 메모리를 확보할 수 있다. 1. Metric Server 설치 Horizontal Pod Autoscaling 적용하기 1번을 참조한다. 2. CPU 리소스 확인 Horizontal Pod Autoscaling 적용하기 2번을 참조한다. 3. Vertical Pod Autoscaler 배포 하단..

0. HPA(Horizontal Pod Autoscaling)이란 Horizontal Pod Autoscaling은 Node에 배포된 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 Scale Out하고 Scale In하는 기능을 말한다. 비슷한 기능으로 Vertical Pod Autoscaling이 있는데, 이는 HPA와는 달리 Pod에 할당된 resource request 값을 적절히 조절하여 pod의 "크기"를 조정하는 것이다. 1. Metric Server 설치 Metric Server는 각 Pod와 Node의 리소스 사용량을 확인할 수 있는 컴포넌트이다. 아래의 명령어를 통하여..

0. 개요 Amazon Elastic File System(Amazon EFS)은 AWS 클라우드 서비스와 온프레미스 리소스에서 사용할 수 있는 간단하고 확장 가능하며 탄력적인 완전 관리형 탄력적 NFS 파일 시스템을 제공한다. 아래의 내용에서는 helm을 이용하여 생성한 EFS 볼륨을 pod에 붙여 Gitlab Runner를 통해 자동 배포하는 과정을 기술한다. 1. EFS 생성하기 1.1 보안 그룹 생성 EFS에 적용할 보안 그룹을 생성한다. EC2 - Security Group - 'Create security group'을 클릭한다. 보안 그룹의 이름과 Description을 기입하고, VPC를 선택한 후, Inbound rule을 추가한다. Inbound는 EKS의 Worker Node 보안 그..

1. 목적 이 글은 Kubernetes 기반 시스템에서 Istio를 이용하여 Blue/Green 배포를 구성하는 방법을 설명하고 있다. 구성 환경은 GCP GKE 1.18.20-gke.501 버전과 Istio 1.10.0 버전으로 Kubernetes Service mesh 환경을 구현하였다. CI/CD 툴은 Gitlab, Gitlab runner를 사용한다. 2. Blue/Green Deployment Blue/Green Deployment는 현재 운영중인 버전(Blue)과 새로운 버전(Green)의 서버들을 동시에 나란히 구성하고 배포 시점이 되면 트래픽을 일제히 전환시키는 배포 방식이다. 운영 환경에 영향을 주지 않고 실제 서비스 환경으로 새 버전 테스트가 가능하고, 빠른 롤백이 가능하다는 것이 장점..