쿠버네티스
-
K8S ArgoCD 설치 (feat. Helm3)K8S 2021. 6. 25. 15:26
Helm3 설치 curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh chmod 700 get_helm.sh ./get_helm.sh Helm 레포지토리에 argocd 추가 helm repo add argo https://argoproj.github.io/argo-helm Repository update helm repo update argo repository 목록 확인 helm search repo argo argo cd 설치 helm install repo argo/argo-cd 권장사항은 포트 포워딩이지만 필자는 Nodeport로 edit해서 사용한다. kubectl edit svc repo-..
-
Istio Circuit breaking 정리K8S 2021. 6. 25. 11:03
이번 포스팅은 이스티오의 circuit breaking에 대해 다룬다. 마이크로 서비스 아키텍처에서 가장 일반적인 문제는 cascading failure다. 어떤 이유로든 서비스가 응답하지 않는 경우, 서비스에 요청을 반복적으로 보내면 대기시간이 길어지고 서비스에 불필요한 부하가 발생한다. 한 서비스의 부하는 다른 서비스의 부하로 이어지는데 이런 현상을 cascading failure라 한다. 이때 circuit breaking을 통해 과부하된 서비스의 연결을 끊고 서비스가 회복할 시간을 줄 수 있다. 예시를 통해 확인해보자. 다음은 fleet-staff-service에서 risky와 safe으로 트래픽을 보내는 경우다. safe의 경우 200 응답이 오지만, risky는 종종 5xx에러의 응답이 온다...
-
Istio Header based routing를 이용한 Dark ReleaseK8S 2021. 6. 25. 01:33
이번 포스팅은 이스티오만의 배포방식인 dark release에 대해서 다룬다. dark release란 개발자가 새로운 버전의 어플리케이션 개발시 test서버에서 testing을 거치지 않고 바로 Production Level에서 testing을 할 수 있는 어플리케이션 배포 방식으로 특정 사용자만 새로운 버전의 애플리케이션 서비스를 경험 및 테스트할 수 있다. 어떻게 특정 사용자만 새로운 버전의 애플리케이션을 사용할 수 있을까? 이는 이전 포스팅에서 다룬 header based routing를 이용한다. Istio Ingress Gateway 정리2 (Prefix based routing, Header based routing) Istio Ingress gateway 정리 k8s의 Ingress는 클러..
-
Istio Ingress Gateway 정리2 (Prefix based routing, Header based routing)K8S 2021. 6. 24. 00:32
Istio Ingress gateway 정리 k8s의 Ingress는 클러스터 외부에서 접근하고 트래픽을 원하는 서비스로 보낼 수 있는 오브젝트다. 그리고 이스티오 서비스 매쉬에서도 ingress gateway라는 모델을 제공하는데 어떤 차이가 있어서 새 seungjuitmemo.tistory.com 이번 포스팅은 istio ingress gateway를 이용한 prefix based routing과 header based rotuing에 대해서 다룬다. prefix 매칭이란 front로 들어오는 uri가 특정 Rule과 매칭되면, 특정 룰에 맞게 routing하는 것이다. prefix 매칭은 정확하게 매칭되지 않아도 된다. 예를들어 룰은 /abc, 실제 들어온 경로가 /abcd라면 /abc로 들어왔다고..
-
Istio Ingress gateway 정리(Weighted routing, Canary)K8S 2021. 6. 22. 17:28
k8s의 Ingress는 클러스터 외부에서 접근하고 트래픽을 원하는 서비스로 보낼 수 있는 오브젝트다. 그리고 이스티오 서비스 매쉬에서도 ingress gateway라는 모델을 제공하는데 어떤 차이가 있어서 새로운 모델을 제공한걸까? 다음 상황을 통해 이해해보도록 하자. 다음 yaml을 apply 한다. apiVersion: apps/v1 kind: Deployment metadata: name: api-gateway spec: selector: matchLabels: app: api-gateway replicas: 1 template: # template for t..
-
Istio Session Affinity 정리K8S 2021. 6. 22. 15:15
이스티오에서는 Consistent hashing을 이용하여 session을 유지할 수 있다. consistent hasing이란? 공식문서를 참고해보면 다음과 같다. 로드밸런서에서는 hash 알고리즘을 이용하여 client로부터 받은 데이터를 hashing한 후 데이터를 포드로 전송한다. 이 때 해쉬된 값을 이용하여 sticky session을 유지한다. 이스티오에서는 다음과 같이 consistent hasing에 대한 속성들을 제공한다. ※ 참고 이스티오에서 stickey session과 카나리를 위한 virtual service의 weighted 옵션을 동시에 사용할 수 없다. weight 옵션과 consistentHash가 설정된 virtual service에서는 weighted 옵션만 적용되어 나..
-
Istio kiali를 이용한 카나리 구성과 virtual service, destination rule 정리K8S 2021. 6. 21. 10:58
이번 포스팅에서는 키알리를 이용해서 카나리를 구현하고 생성된 virtual service와 destination rule에 대해서 알아본다. 1. 키알리를 이용한 카나리 구현 다음은 Kiali dashboard를 통해서 본 fleetman-staff-service 서비스로 들어온 트래픽을 staff-service deploylment와 staff-service-risky-version deployment 워크로드로 로드밸런싱하는 상황이다. (staff-service-risky-version가 카나리가 된다!) (api-gateway와 Position-tracker는 무시하자) a..
-
K8S Operating System UpgradeK8S 2021. 6. 17. 15:55
이번 포스팅에서는 클러스터 내의 노드 패치 또는 업그레이드시 노드를 unschedule하는 방법에 대해 다룬다. 다음 상황을 가정한다. 나는 쿠버네티스 클러스터 내 node를 패치하거나 업그레이드하고 싶다. 이때 노드 내의 포드는 노드 업그레이드 시 문제가 생길 수 있기 때문에 우선 노드를 unscheule한 상태로 만들어준다. 이때 노드내 포드가 만약 replicas로 지정된 포드라면 노드에 장애가 생겨도 self-healing되어 문제가 없으므로 노드 내 모든 포드를 지운 후, unschedulable하게 해도 괜찮다. 하지만 replicaset이 지정되어 있지 않은 포드가 노드 내 존재한다면 노드 내 포드만 그대로 놔두고 노드를 Unschedule하게 한다. 이번 포스팅에서는 Replicas가 설정..