k8d

/.kube/configcurrent-context 가 중요하다.실제로는 다중 클러스터로 운영이 되는데, 현재 바라보고 있는 클러스터가 무엇인지 명세할 수있다.변경조회현재 컨텍스트 확인

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

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

클러스터 안에서 자원 할당이 가능한 노드 중 알맞은 노드를 선택하는 역할Label / Selector / Affinity / Taint / Tolerationpod를 수동으로 manually하게 schedule 해야한다.pod.yaml사용자가 특정 노드에 Pod를 배치

다양한 컨트롤러를 구성하는 요소노드 컨트롤러, 잡 컨트롤러, 엔드포인트 컨트롤러, 레플리케이션 컨트롤러 등다양한 컨트롤러를 모니터링하고 관찰5s 마다 status check ( node monitor period )heart beat가 도착하지 않으면, 40s 대기 후

kublet ( kubernetes data plane ) >

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

실제로 컨테이너를 실행시키는 런타임 환경저수준runc, runv ...고수준containerd, CRI-O, docker ...

kubernetes 클러스터 내부 주소의 해석이나 서비스 디스커버리에 사용되는 내부 DNS 서버 (add-on)

출처 https://banzaicloud.com/blog/k8s-custom-scheduler/

controll plance 영역이 AWS EKS 영역으로 완전 관리형으로 제공된다.AWS가 kubernetes 마스터 노드를 관리하고, 사용자는 worker node 혹은 data plane 영역을 관리한다.극단적으로 말하면, 1단원부터 10단원까지 중 contol

워크로드가 돌아가는 컨테이너를 배치하는 물리(가상) 머신control plane에 의해 관리됨.일반적인 운영환경에서는 multi node로 운영각 노드는 kube-proxy, container-runtime, kubelet이 포함.동일 물리 클러스터를 기반으로 하는 복

kubectx > kubectl의 컨텍스트 간에 전환을 도와주는 도구 kubens > kubernetes 네임스페이스 간 쉽게 전환하고 kubectl에 맞게 구성하는 도구

kubernetest 패키지 관리자Chart 라고 불리는 패키지들을 관리template과 values.yaml 파일을 이용해 어플리케이션을 구성차트에 대한 정보차트 라이센스에 대한 정보차트에 대한 설명 파일차트의 의존성을 명시한 파일이 차트에서 사용하는 기본 설정 값이

AWS에서 개발한 kubernetes의 Worker Node의 오토 스케일러CA와 비슷한 역할을 수행하지만, CA는 AWS 리소스의 의존성이 강한 반면karpenter는 AWS 리소스 의존성 없이 JIT ( Just In-Time )배포 가능helm 차트로 패키징해서

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

공식문서설치 링크etcd-controlplane이 있는지 확인실제로 16진수로 확인해보면 우리가 만든 secret의 데이터가 암호화되지 않은채로 ETCD에 저장되어있다.이것은 큰 문제인데 왜냐면, ETCD에 접속할 수 있는 모든 사람은 데이터를 볼 수 있기 때문이다.

vagrant up --provider=parallesvagrant ssh worker1cd /home/vagrantsudo ./join.shcp -R ./.kube ~/워커노드 2, 3에도 동일하게 적용

우측 상단에 STANDARD 클러스터로 전환 클릭리전 northeast3:ak8s 버전 선택노드 풀이름이나 노드 수 같은 거 설정머신 구성에서 SPEC 선택머신유형과 디스크 선택Google Cloud CLI 설치 링크

1. 환경구성 for k8s 2. Container RunTime Containerd 3. k8s 4. CNI 5. Dashboard

위 명령어를 수행하면 도커 컨테이너가 뜨는데,실제로 nginx를 접속하기 위해서는내 IP의 8001번으로 들어가야한다.그 전에로 도커 내부 IP를 보면 172.17.0.2와 같은 IP가 나온다.즉, 내 IP의 8001번으로 들어가면도커 내부 IP의 80번으로 변환을 한

링크

EBS 설치

링크다음 crd들을 통해 발급되는 certificate에 대한 확인을 해볼수 있음certificaterequests : issuer로부터 X.509 인증서를 요청하는데 사용되는 자원이다.order : signed TLS 인증서에 대한 ACME 주문의 전체 사이클을 관리

kubeadm, kubectl, kubelet -> unhold노드 단위로 관리한다.drain(삭제)kubeadm, kubectl, kubelet -> unhold노드 단위로 관리한다.drain(삭제)

1. zookeeper 2. Kafka

Secret 토큰과 Webhook url을 추후 Gitlab에 입력해야함.Gitlab webhook URL문구 뒤에 주소가 나오는데 해당 주소를 기억해야한다. Build Triggers 안에 Advanced를 누르면 Secret Token이 나오는데Generate버튼을

1. 인증서 생성 Private Key CSR 인증서 K8s Secret

메모리 증설을 위해 마스터와 워커노드 VM 들을VSphere에서 Shutdown 하고 메모리 증설 이후 다시 실행했는데,kubectl 명령어를 치면 에러가 발생.에러위 현상은 kube-apiserver가 실행에 문제가 있을 때 발생하기 때문에 추적을 시도한다.Kubel

kube-scheduler와 kube-controller-manager가 역시 문제가 있어보인다왜냐? 9분전, 21분전에 컨테이너가 새로 떴다는 말은 주기적으로 재생성되고 있었을 가능성이 크다.Wow! 리더 선출을 위한 리소스 잠금을 가져오는 도중 네트워크 요청 시간이

IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. Pod, Namespace, IPBlock의 3가지 타입으로 제어

보안은 계층으로 생각할 수 있다. 클라우드 네이티브 보안의 4C는 클라우드(Cloud), 클러스터(Cluster), 컨테이너(Container)와 코드(Code)이다.클라우드 계층이 취약하거나 취약한 방식으로 구성된 경우 이 기반 위에서 구축된 구성 요소가 안전하다는

privileged 정책은 의도적으로 열려있으며 전적으로 제한이 없다.이러한 종류의 정책은 권한이 있고 신뢰할 수 있는 사용자가 관리하는 시스템 및 인프라 수준의 워크로드를 대상으로 한다.특권 정책은 제한 사항이 없는 것으로 정의한다.기본으로 허용하는 메커니즘(예를 들

기본적인 컴퓨터 네트워크 가상화 서버 네트워크

부제: “짝수로 하면… 싸움 난다구요 🤺”쿠버네티스 클러스터를 만들다 보면 이런 얘기 꼭 듣습니다:“마스터 노드는 홀수로 맞추세요~”아니, 서버 갯수를 맞추는데 왜 갑자기 홀수 클럽 가입을 강요하는 걸까요?짝수도 좋은 숫자인데 왜? 🤔쿠버네티스의 모든 상태는 etc

부제: “리더 없이는 아무것도 못 하는 우리 팀” 분산 시스템에서 제일 무서운 순간은?👉 “누가 리더냐?” 하는 순간입니다. MongoDB, Zookeeper, Kafka, etcd… 다들 합의 알고리즘으로 Raft를 쓰거나 영향을 받았죠.Kubernetes의 e

"나는 분명 kubectl apply 했을 뿐인데…"쿠버네티스 쓰다 보면 가장 많이 보는 에러 상태 1위: Pod가 뜨긴 뜨는데, 몇 초 지나면 죽고, 다시 뜨고, 또 죽고…결국 kubectl get pods 찍으면 무한 루프처럼 CrashLoopBackOff 🌀이

“쿠버네티스 Ingress, DNS, 그리고 나의 멘탈”쿠버네티스 서비스에 도메인 붙이는 순간이 옵니다.“외부에서 myapp.example.com으로 접속되게 해주세요~” 👉 여기서부터 실수 퍼레이드가 시작됩니다.(실무자라면 누구나 한 번쯤 겪는 고통…)DNS A

"kubectl 없이는 오늘도 출근 못합니다"쿠버네티스를 쓰다 보면…Pod가 안 떠요.서비스가 안 붙어요.이벤트가 안 찍혀요. 이럴 때 DevOps가 꺼내 드는 무기는 바로:👉 kubectl과 각종 디버깅 명령어! 오늘은 그 중에서도 실무에서 진짜 자주 쓰는 To

부제: "yes/no 하나에 인프라 운명이 갈린다"Terraform은 인프라 IaC의 구세주입니다.terraform apply 한 방이면 서버, DB, 네트워크, 로드밸런서까지 전부 자동화 🚀 하지만…가끔은 이 apply 버튼이👉 서비스 킬 스위치처럼 느껴질 때가