ybchoi

linkerd-viz 배포시 기본옵션은 그라파나,프로메테우스가 다 배포되어진다 물론 해당 그라나파와 프로메테우스는 linkerd에서만 사용하므로 따로 써도 무방하나 나처럼 기존에 사용하던 그라파나와 프로메테우스를 이용하고 싶다면 아래의 방법대로 하면 된다 먼저 기존 프로메테우스에 linkerd 스크랩 정책을 추가하여 준다 {{}} 안에는 실제 사용하는 값을 넣어야함(linkerd ns) - job_name: 'linkerd-controller' kubernetes_sd_configs: - role: pod namespaces: names: - '{{.Values.linkerdNamespace}}' - '{{.Values.namespace}}' relabel_configs: - source_labels: ..

Istio VS Linkerd https://buoyant.io/linkerd-vs-istio Linkerd vs Istio buoyant.io istio가 레퍼런스는 많지만 헤비한 시스템이라 Linkerd를 선정하고 클러스터에 올려 테스트 수행 1. linkerd CLI 설치 curl --proto '=https' --tlsv1.2 -sSfL | sh or brew install linkerd 설치확인 % linkerd version Client version: stable-2.11.2 Server version: unavailable 2. linkerd로 클러스터 체크 % linkerd check --pre there are nodes using the docker container runtime a..

https://github.com/kubernetes-sigs/descheduler GitHub - kubernetes-sigs/descheduler: Descheduler for Kubernetes Descheduler for Kubernetes. Contribute to kubernetes-sigs/descheduler development by creating an account on GitHub. github.com Kubernetes Scheduler의 한계점을 약간 보완해주는 프로젝트 Pod의 상태를 확인하여 조건에 성립하는 Pod를 Eviction하여 원하는 상태로 만듬 Eviction이후의 동작은 Scheduler가 수행하므로 원하는대로 동작이 안될수도 있다 Job,Cronjob,Deplo..

ingress는 특성상 네임스페이스 별로 만들어야 하는데 ingress-alb 사용시 인그레스 생성시마다 alb가 생성되어 비용이나 관리 측면에서 좋지않음 1개의 alb로 여러개의 인그레스를 사용하려면 네임스페이스가 같다면 한번에 만들면되니 문제가 없으나 네임스페이스가 다른 경우에는 아래의 방법을 사용하면 된다 IngressGroups를 사용하여 여러 서비스 리소스 간에 Application Load Balancer 공유 그룹 수신에 가입하려면 Kubernetes 수신 리소스 사양에 다음 주석을 추가합니다. alb.ingress.kubernetes.io/group.name: my-group 그룹 이름은 다음과 같아야 합니다. 63자 이하의 길이여야 합니다. 소문자, 숫자, - 및 .으로 구성됩니다. 글자..

ingress 상태에 아래와 같이 메시지 출력됨 / ssl-redirect:use-annotation () ssl-redirect는 정상 작동 중임 현재는 아래와 같이 manifest가 선언되어있음 apiVersion: extensions/v1beta1 kind: Ingress metadata: namespace: default name: ingress annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxx:certificate/xxxxxx alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS"..

jenkins 와 argocd 를 사용하여 CI/CD를 하는 Gitops를 사용하고 있다 argocd의 경우 배포용 레포가 존재하는데 해당 레포에 시크릿 데이터가 올라간다 레포에 보안을 설정하긴 하겠지만 평문(base64인코딩이며 절대 암호화가 아님)으로 저장되는것이 불안하다면 이미 여러가지 솔루션이 있다 나의 경우 간단하게 도입이가능하고 딱 레포에 시크릿을 암호화하고싶다는 니즈만 있었으므로 Sealed secrets을 사용함 https://github.com/bitnami-labs/sealed-secrets/ GitHub - bitnami-labs/sealed-secrets: A Kubernetes controller and tool for one-way encrypted Secrets A Kubern..

기본으로 설치시 구성되는 SC는 csi를 사용하지 않음 즉 과거의 방식(k8s가 직접 aws와 통신하여 볼륨을 생성하고 제어함) 임 csi드라이버(eks에서 추가기능으로 설치 가능)를 설치하고 provisioner를 ebs.csi.aws.com 로 하는 sc를 생성하여 사용한다 이경우 k8s → csi → aws로 제어되며 aws에서 직접 볼륨을 컨트롤 함 최근에는 csi를 쓰는 방식이 보편화 되어있고 k8s provisioner는 안쓰는 추세(업그레이드가 안됨)이므로 csi를 사용하도록 한다

이하 PDB 각 파드 컨트롤러에 최소/최대 유지 갯수를 설정한다 오브젝트를 따로 설정하여야함 apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: zk-pdb spec: maxUnavailable: 1 selector: matchLabels: app: zookeeper maxunavailable(최대 사용불가능한 파드)과 minavailable(최소로 살아있어야 하는 파드)을 이용하여 설정한다 관리자가 강제로 여러노드에 drain을 걸거나 했을때 일반적인 replicas로 만은 보호되지 않는 파드의 최소 구동을 보호하여 준다 다만 노드장애나 전체적인 시스템 장애등의 상황에서는 어쩔수 없고 예상가능한 상황에서의 보호장치라고 보면 될듯