Kubernetes

Grafana는 RabbitMQ를 위한 대시보드 템플릿을 제공하고 있기 때문에, 컨테이너 환경에서 실행되는 RabbitMQ 메트릭을 Prometheus로 내보내는 방법을 소개합니다.

Amazon EKS Cluster를 배포하는 방법은 크게 3가지가 있습니다. -EKS console -eksctl -IaC (Terraform, Cloud Formation 등)

Namespace란? - K8S cluster 내의 논리적인 분리 단위로써, 'Live', 'QA' 등 서비스 목적에 따라 리소스들을 격리하여 관리할 수 있는 공간이다.

EKS에서 Pod 배포를 EC2 node가 아닌, fargate에 스케쥴링 하기 위해서는 'Fargate Profile'을 사전에 구성해야 한다.Namespace 별로, Fargate Profile을 추가 생성 : namespace별로 pod가 배치되도록, Pod

configmap 파일 내용 변경이 필요하여, 수정할 경우 기존 pod가 재 배포된다.<기존 CoreDNS configmap 파일 수정>coredns를 변경된 Fargate Profile을 통해 배포하기 위해서는 coredns deployment를 edit하여 e

개 요 EKS on Fargate는 Fluent Bit를 기반으로 내장된 로그 라우터를 제공 Amazone이 Fluent Bit 컨테이너를 사이드카로 자동 실행함로그 라우터를 사용하면 Fargate에서 Amazon CloudWatch로 로그를 직접 스트리밍할

Kubernetes 클러스터의 자동 스케일링을 위해 기본으로 제공되는 두 가지 도구가 있습니다. 바로 Horizontal Pod Autoscaler(HPA)와 Cluster Autoscaler(CA)입니다. 그 중에 여기서는 HPA에 대해 집중적으로 설명합니다.

< Cluster 접근 권한 >AWS IAM 계정에는, default로 아무 권한이 없어서, EKS cluster에 접근할 수 있는 권한을 부여해야 합니다.참조 문서(https://docs.aws.amazon.com/ko_kr/eks/latest/user

EKS의 pod와 EC2 인스턴스끼리 내부 통신의 구현이 필요한 경우 아래와 같은 절차를 진행한다. 1) VPC Peering (EKS <-> EC2) 2) Routing Table (EKS -> EC2) => Peering Connec

< K8S Deployment 생성 >사전작업) deployment 매니페스트 파일(.yaml) 작성1) awscli를 사용하여, eks cluster에 접속2) deployment 배포< K8S Service 생성 >1) Service 매니페스트 파일(.y

목표 : Deployment로 배포한 Pod의 갯수를 live하게 scale-out / scale-in 할 수 있다. \* replicas 값을 '0'으로 설정하면, 운영 pod 개수를 0개로 떨어뜨리는 것이 가능하다. kubectl get deployment -n

목표 : 동작 중인 컨테이너의 셸에 접근한다. kubectl get pod -n <Namespace 이름> kubectl exec --stdin --tty <pod 이름> -n <Namespace 이름> -- /bin/bash 또는 kubec

TLS는 오늘날 거의 모든 서비스에서 기대되는 기본 보안 요소이며, NLB와 연계하면 이를 간소화하고 최적화할 수 있습니다. 거의 모든 웹 및 네트워크 서비스에 데이터 전송 암호화가 요구되는 상황에서, NLB에 TLS를 연동하는 것은 통신 보안과 서비스 효율성을 모두

pod 로그ingress 로그

< Calico >K8S용 네트워크 정책 엔진으로서, 특정 namespace 및 pod에서 network 트래픽을 제어pod 및 container에 대한 방화벽 역할을 함kube-system에 demonset으로 설치 -> node 당 하나씩 들어감< 특정

'Docker Hub', 'Harbor' 등 컨테이너 이미지를 저장하고 관리하는 기능을 AWS에서 제공하는 managed 서비스로 이용할 수도 있다. 바로 ECR(Elastic Container Registry)이다.

기존 EKS ingress 배포 시, kubernetes yaml 상에서는 Source ip를 제한하는 방법이 없어서, 관리 port들이 any로 노출되기 때문에아래와 같이 관리 port들을 특정 Source ip에서만 접근 가능하도록 제한하는 Security Grou

쿠버네티스에서 사이드카 패턴을 사용하는 것은 여러 가지 이점이 있습니다. 사이드카 패턴은 애플리케이션 컨테이너와 함께 보조적인 역할을 하는 컨테이너를 동일한 파드(pod) 내에 정의하여 주요 애플리케이션의 기능을 확장하거나 보완하는 방식입니다.다음은 pod의 '로그 수

kubernetes의 여러 노드 중에 특정 노드에 pod를 배포하고 싶을 경우, 몇 가지 방법이 있지만 'node selector'를 사용하는 방법을 설명합니다.spec:template:spec: \- nodeSelector: \---- worker: nod

EKS에 pod를 배포했는데, 아래와 같은 error가 발생할 경우가 있다.exec ./BackendServer: exec format error위 에러는, 여러가지 원인으로 인해 발생할 수 있지만,내가 경험한 환경 상에서 발생한 원인은, 컨테이너 이미지와 Node의

kubernetes 클러스터를 운영 시, 보게 되는 에러 중 가장 많은 빈도를 차지하는 것이 아래 에러일 것 같다.OOMKilledPod 배포가 정상적으로 완료되지 않아서, description을 확인해 봤을 때 위와 같은 에러가 표시되고 있다면,컨테이너에 할당된 메모

k8s를 관리하기 위해 kubectl 이라는 명령어를 매우 많이 사용하다보니 줄여쓰는 문화가 많이 있습니다.줄여쓰기만 하다가 원래 명령어가 뭔지 잊어버릴까봐 안 쓰고 있었는데,남들 다 하는 거 한 번 적용해 봤습니다.kubectl을 이용하는 OS별로 줄여쓰는 방법을 정

EKS cluster에서 ingress를 생성하면, LB 컨트롤러에 의해 ELB가 자동으로 배포됩니다.이 때, ELB를 external로 만들 지, internal로 만들 지 모드를 선택해야 하는데, external로 만들면 ELB에 public sunet이 매핑되고i

애플리케이션 배포(Deployment) 전략은 여러 가지가 있는데, Kubernetes(K8s)가 기본적으로 지원하는 전략과, 직접 구현하거나 서드파티 CD 도구(Argo Rollouts 등)가 필요한 전략이 구분됩니다.