kubecost > K8s 환경에 대한 비용 분석 및 비용 최적화, 성능 관리, Alert를 제공하는 FinOps 솔루션 Dashboard 형태로 구성되어 가시성 제공 kubecost 사전 조건 EC2 Worker node kubectl helm Amazon EBS CSI 드라이버

AWS에서 개발한 kubernetes의 Worker Node의 오토 스케일러 CA와 비슷한 역할을 수행하지만, CA는 AWS 리소스의 의존성이 강한 반면 karpenter는 AWS 리소스 의존성 없이 JIT ( Just In-Time )배포 가능 karpenter > helm 차트로 패키징해서 배포 가능. karpenter 컴포넌트 karpenter pod Controller - pod 상태를 감시하고 Node를 확장 및 축소 Webhook - Provisioner CRD에 대한 유효성 검증 및 기본값 지정 provisioner CRD Karpenter에 의해 생성되는 Node와 pod에 대한 제약조건을 지정하는 template

Helm > kubernetest 패키지 관리자 Chart 라고 불리는 패키지들을 관리 template과 values.yaml 파일을 이용해 어플리케이션을 구성 helm chart 구성 요소 Chart.yaml 차트에 대한 정보 LICENSE 차트 라이센스에 대한 정보 README.md 차트에 대한 설명 파일 requirements.yaml 차트의 의존성을 명시한 파일 values.yaml 이 차트에서 사용하는 기본 설정 값 charts/ 이 차트에 관련되어 있는 차트들 templates/ 매니페스트 파일들로 변환될 yaml 템플릿 templates/NOTES.txt 짧은 사용법 설명

kubectx > kubectl의 컨텍스트 간에 전환을 도와주는 도구 kubens > kubernetes 네임스페이스 간 쉽게 전환하고 kubectl에 맞게 구성하는 도구 설치 매뉴얼 > kube-ps1의 설정을 zshrc에 추가 해야함.

1. worker node > 워크로드가 돌아가는 컨테이너를 배치하는 물리(가상) 머신 control plane에 의해 관리됨. 일반적인 운영환경에서는 multi node로 운영 각 노드는 kube-proxy, container-runtime, kubelet이 포함. 2. namespace > 동일 물리 클러스터를 기반으로 하는 복수의 가상 클러스터를 지원하는 개념 클러스터를 논리적으로 나누고 액세스를 제한하여, 리소스 생성 및 관리 논리적으로 구별될뿐 격리되는 것이 아님. (격리 시키기 위해서는 network policy와 같은 오브젝트를 추가로 사용해야함.) 3. Pod > kubernetes 최소 단위 객체 하나의 pod는 여러 컨테이너 포함 가능 MSA의 decoupling에 의하면 사실상 1 pod 당 1 container가 정석이다. > 하나의 pod안에서 동작하는 특정 컨테이너의 로그를 수집해

EKS > controll plance 영역이 AWS EKS 영역으로 완전 관리형으로 제공된다. AWS가 kubernetes 마스터 노드를 관리하고, 사용자는 worker node 혹은 data plane 영역을 관리한다. 극단적으로 말하면, 1단원부터 10단원까지 중 contol plane 영역에 있던 etcd라던지, apiserver등 설치나 고민할 필요가 없다. 네트워크 영역 > AWS EKS의 control plane 영역과 사용자의 data plane영역의 VPC가 분리 되어있다. AWS EKS의 contol plane이 위치한 VPC 영역에 네트워크 로드 밸런서가 존재한다. 사용자의 워커 노드는 NLB의 스태틱한 엔드포인트로 접근할 수있게 된다. 사용자의 data plane이 위치한 VPC내 subnet에 ENI가 존재한다. EKS의 control plane > 고 가용성을 위해 Mutli

Pod가 생성되는 과정 출처 https://banzaicloud.com/blog/k8s-custom-scheduler/

coredns > kubernetes 클러스터 내부 주소의 해석이나 서비스 디스커버리에 사용되는 내부 DNS 서버 (add-on) coredns 구성 확인 dns 호출 테스트

container-runtime > 실제로 컨테이너를 실행시키는 런타임 환경 저수준, 고수준의 런타임 저수준 > runc, runv ... 고수준 > containerd, CRI-O, docker ... container-runtime 구성 확인

kube-proxy > 클러스터 내 각 node에서 실행되는 네트워크 프록시 가상 네트워크의 동작을 관리 IP Translation과 라우팅 노드나 Pod끼리 통신을 가능하게 해준다. kube-proxy 구성 확인

Data Plane > 여기에 해당하는 노드들은 worker node라 부른다. 이 노드들은 pod를 구동하기 위한 서비스가 있고, 마스터 컴포넌트에 의해 관리된다. kubelet ( kubernetes data plane ) > 각 kubernetes 노드에서 동작하는 node agent 컨테이너 런타임과 연계하여 컨테이너 기동 및 정지 등을 관리 pod 스펙 설정을 kube-apiserver로부터 전달받아 pod 컨테이너의 실행을 직접적으로 관리 pod가 아닌 프로세스의 형태로 뜬다. kubelet 구성 확인

controller-manager > 다양한 컨트롤러를 구성하는 요소 노드 컨트롤러, 잡 컨트롤러, 엔드포인트 컨트롤러, 레플리케이션 컨트롤러 등 다양한 컨트롤러를 모니터링하고 관찰 컨트롤러 동작 예시 노드에 문제가 생겼을 때 5s 마다 status check ( node monitor period ) heart beat가 도착하지 않으면, 40s 대기 후 unreachable로 마킹 ( node monitor grace period ) 추가로 5m 대기 ( pod eviction timeout ) 복구되지 않으면 해당 node의 pod들을 정상 node로 재배포 ( replicaset에 해당되는 경우 ) cloud-controller-manager > 쿠버네티스 컨트롤러들을 클라우드 서비스 API와 연결해서 관리하는 컴포넌트 on premise 환경은 해당 manager가 없음.

ㅁ kube-scheduler > 클러스터 안에서 자원 할당이 가능한 노드 중 알맞은 노드를 선택하는 역할 Label / Selector / Affinity / Taint / Toleration 만약 kube-scheduler가 없다면? > pod를 수동으로 manually하게 schedule 해야한다. pod.yaml binding.yaml ㅁ 스케쥴링 분류 사용자가 특정 노드에 Pod를 배치하고자 할 때 > Affinity, Selector ... 관리자가 특정 노드에는 Pod가 배치되는 것을 막고자 할 때, > Taint , Tolerations kubernetes controll node에는 pod가 스케쥴링 되지 않도록 taint 되어있다.

kube-apiserver > 쿠버네티스 API를 제공하는 핵심 구성 요소 쿠버네티스 프론트엔드로서 클러스터로 온 요청의 유효성 검증 다른 컴포넌트 간 통신을 중재 kubectl 유틸리티가 접근하는 주체 kube-apiserver 구성 확인

etcd > 쿠버네티스에 필요한 모든 데이터를 키-값 형태로 저장하는 DB etcd가 다운되면 모든 컴포넌트는 미아가된다. 즉, high-availability가 중요하다. etcd 구성 확인

Kube Config 파일 위치 > /.kube/config > current-context 가 중요하다. 실제로는 다중 클러스터로 운영이 되는데, 현재 바라보고 있는 클러스터가 무엇인지 명세할 수있다. Context 변경 조회 현재 컨텍스트 확인 노드 확인 네임스페이스 확인 Pod 확인