쿠버네티스

전체 클러시터 관리를 담당하는 노드로 k8s 워커의 오케스트레이션을 처리함특징으론 단일 실패 지점 회피를 위한 복제 기능을 가짐API 서버쿠베네티스 컨트롤 플레인의 프론트엔드로 쿠버네티스 클러스터를 정의하고 구성하기 위해 RESTFul 웹 서비스를 제공함etcd시스템에

컨테이너 오케스트레이션이란 무엇입니까? 컨테이너 오케스트레이션은 컨테이너의 라이프사이클을 관리하는 체계입니다. 클랑드 네이티브 애플리케이션의 각 컨테이너들을 수동으로 관리하는 것은 불가능하다고 할 수 있습니다. 따라서 클라우드 네이티브 아키텍처에 컨테이너 오케스트레이

디플로이먼트 (Deployment): 파드를 만드는 추상 단위입니다. 서비스를 배포하기 위해선 파드 내에서 실행해야 합니다. 이를 위해 애플리케이션 복제본 수와 배포해야 할 사항을 설명하는 디플로이먼트 구성이 생성됩니다. 이 구성을 K8s에 게시하면 구성된 복제본과 함

쿠버네티스 서비스란 무엇입니까 쿠버네티스 파드는 소모품이며 레플리카셋에 의해 오토스케일링 시 생성되고 제거됩니다. 따라서 IP 주소로 파드에 액세스하는 것은 권장되지 않습니다. 이 문제를 해결하기 위해 쿠버네티스에선 쿠버네티스 서비스란 개념을 활용합니다. 쿠버네티스는

마이크로서비스 아키텍처를 채택하고 마이크로서비스 패턴을 직접 구현할 때 팀은 비즈니스 로직과 관련 없는 부분에 많은 시간 투자를 하게 됩니다. 또한 서비스 간의 통신을 구현하기 위해 추가적인 학습이 필요합니다. 이러한 패턴은 조직의 Time To Value를 저하시키고

애플리케이션의 고가용성을 보장하기 위해선 부하에 따라 스케일링 작업이 필요합니다. 서비스 디스커버리는 새 작업을 수행할 준비가 된 사용 가능한 서비스 노드를 추적합니다. 서비스 노드를 더 이상 사용할 수 없는 경우 서비스 디스커버리는 사용 가능한 노드 목록에서 해당 노

가상 서비스는 여러 개의 마이크로서비스를 하나의 가상 서비스로 노출시키는 역할을 합니다. 즉, 클라이언트가 실제로는 여러 개의 마이크로서비스를 호출하더라도 가상 서비스를 호출하게 됩니다. 이를 통해 클라이언트는 마치 하나의 서비스를 호출하는 것처럼 투명하게 사용할 수

매니지드 쿠버네티스 서비스란 무엇입니까? 매니지드 쿠버네티스 서비스는 벤더에서 관리하는 쿠버네티스 클러스터를 제공하는 서비스입니다. 이 서비스는 쿠버네티스 클러스터를 배포, 관리, 확장하는 복잡한 작업을 자동화하여 사용자로 하여끔 쉽게 쿠버네티스를 사용할 수 있도록

컨테이너 5개 생성컨테이너 외부 노출서비스는 포트를 외부로 노출 시키는 기능을 수행

kube-api server는 쿠버네티스 클러스터의 중심 역할을 수행하며, 클러스터의 통신과 제어를 담당하는 핵심 컴포넌트입니다.kube-api server는 Kubernetes 클러스터의 API를 제공하는 컴포넌트로, 클러스터 외부에서의 통신을 관리하고 클러스터 내의

Kube Controller Manager는 클러스터 내의 여러 리소스를 관리하고 클러스터의 상태를 지속적으로 감시하여 안정성을 유지하는 중요한 역할을 수행합니다.Kube Controller Manager는 Kubernetes 클러스터에서 실행되는 여러 개의 컨트롤러를

Kube Scheduler는 클러스터 내에서 애플리케이션 파드를 적절한 노드에 스케줄링하는 역할을 합니다. 즉, 클러스터의 자원 활용과 고가용성을 보장하며, 파드의 수행을 최적화하는데 중요한 역할을 수행합니다.Kube Scheduler는 Kubernetes 클러스터 내

Kubelet은 클러스터 노드의 심장부로, 노드의 상태를 관리하고 마스터와의 통신을 담당합니다. 파드의 생성, 실행 및 모니터링에 핵심적인 역할을 수행하여 클러스터의 원활한 운영을 지원합니다.Kubelet은 Kubernetes 노드에서 실행되는 에이전트로, 클러스터의

Kube Proxy는 클러스터 내부의 네트워크 트래픽을 관리하고, 서비스와 파드를 연결하는 역할을 수행합니다. 이로 인해 클러스터 내부의 서비스 디스커버리와 로드 밸런싱을 제공하며, 안정적인 서비스 제공에 핵심적인 역할을 합니다.Kube Proxy는 Kubernetes

쿠버네티스(Kubernetes)에서는 컨테이너의 상태 체크를 위해 Liveness Probe, Readiness Probe, Startup Probe를 제공합니다. 이러한 Probes는 컨테이너의 상태를 모니터링하고 필요에 따라 자동으로 컨테이너를 재시작하거나 트래픽

레이블 배치 전략은 컨테이너 오케스트레이션 시스템에서 애플리케이션 배포와 관련된 효율성과 유연성을 극대화하기 위해 사용되는 중요한 개념입니다. 이 기술 블로그에서는 레이블 배치 전략이란 무엇인지, 어떻게 동작하는지, 그리고 이를 통해 어떤 이점을 얻을 수 있는지에

애플리케이션을 개발하거나 운영할 때, 대규모의 사용자 요청에 대해 안정적으로 처리하기 위해 여러 대의 서버를 구성해야 할 때가 있습니다. 이때 쿠버네티스(Kubernetes)는 컨테이너 오케스트레이션 플랫폼으로서 많은 도움을 줄 수 있습니다. 쿠버네티스에서는 레플리카셋

쿠버네티스 디플로이먼트는 쿠버네티스 클러스터에서 애플리케이션을 배포하고 관리하기 위한 리소스입니다. 디플로이먼트를 사용하면 애플리케이션의 확장, 롤아웃, 롤백 등을 쉽게 수행할 수 있습니다. 디플로이먼트는 레플리카셋(ReplicaSet)을 생성하고 관리하며, 컨테이너화

컨테이너의 공동 배포된 그룹이며 쿠버네티스의 기본 빌딩 블록을 대표쿠버네티스는 컨테이너를 개별적으로 배포하지 않고 컨테이너의 파드를 항상 배포하고 운영일반적으로 파드는 단일 컨테이너만 포함하지만 다수의 컨테이너를 포함 할 수 있음파드는 다수의 노드에 생성되지 않고 단일

go-http-pod.yaml

jenkins-manual-pod.yaml

컨테이너가 살았는지 판단하고 다시 시작컨테이너의 상태를 스스로 판단하여 교착 상태에 빠진 컨테이너를 재시작버그가 생겨도 높은 가용성포드가 준비된 상태에 있는지 확인하고 정상 서비스 시작포드가 적절하게 준비되지 않은 경우 로드밸런싱 x애플리케이션의 시작 시기 확인하여 가

exec-liveness.yamlhttp-liveness.yamltcp-liveness-readiness.yaml

모든 리소스를 구성하는 매우 간단하면서도 강력한 쿠버네티스 기능리소스에 첨부하는 임의의 키/값 쌍 (예 app:test)레이블 셀렉터를 사용하면 각종 리소스를 필터링하여 선택할 수 있음리소스는 한 개 이상의 레이블을 가질 수 있음리소스를 만드는 시점에 레이블을 첨부기존

http-go-pod-v2.yaml http-go-pod-v3.yaml

nginx-pod.yaml

http-go-rc.yaml

nginx-rs.yaml

jenkins-deploy.yaml

\--record=true는 히스토리 저장성공적으로 배포되었는지 확인"kubectl run -it --rm --image busybox -- bash" 명령어는 Kubernetes 클러스터에서 BusyBox 이미지를 사용하여 인터랙티브한 컨테이너를 실행하는 명령어"ru

오늘은 쿠버네티스(Kubernetes)의 서비스 타입에 대해 상세히 알아보겠습니다. 쿠버네티스는 컨테이너 오케스트레이션 도구로서, 애플리케이션의 효율적인 배포를 지원하는데, 이를 위해 다양한 서비스 타입을 제공합니다. 이러한 서비스 타입들은 각기 다른 특성을 가지며,

포드는 일시적으로 생성한 컨테이너의 집합따라서 포드가 지속적으로 생겨났을 때 서비스를 하기에는 적합하지 않음IP 주소의 지속적인 변동, 로드 밸런싱을 관리해줄 또 다른 개체가 필요이 문제를 해결하기 위해 서비스라는 리소스가 존재함외부 클라이언트가 몇 개이든지 프론트엔드

http-go-deploy.yaml

쿠버네티스의 서비스 기능을 사용하면 외부 서비스와 연결 가능외부 서비스와 연결을 수행할 때는 서비스의 endpoint를 레이블을 사용해 지정하는 것이 아니라 외부 IP를 직접 endpoint라는 별도의 자원에서 설정다음 도큐먼트에는 이런 레이블이 없는 서비스를 사용하는

NodePort: 노드의 자체 포트를 사용하여 파드로 리다이렉션LoadBalancer: 외부 게이트웨이를 사용해 노드 포트로 리다이렉션Ingress: 하나의 IP 주소를 통해 여러 서비스를 제공하는 특별한 메커니즘서비스에 yaml 파일을 작성type에 NodePort를

방화벽 열기

컨테이너가 외부 스토리지에 액세스하고 공유하는 방법파드의 각 컨테이너에는 고유의 분리된 파일 시스템 존재볼륨은 파드의 컴포넌트이며 파드의 스펙에 의해 정의독립적인 쿠버네티스 오브젝트가 아니며 스스로 생성, 삭제 불가각 컨테이너의 파일 시스템의 볼륨을 마운트하여 생성볼륨

공유 스토리지가 없는 동일한 파드의 세 개의 컨테이너두 개의 볼륨을 공유하는 세 개의 컨테이너볼륨을 공유하는 애플리케이션 생성docker build -t gasbugs/count .docker push gasbugs/countdockerfilecount.shcount-

노드의 파일 시스템에 있는 특정 파일 또는 디렉터리 지정영구 스토리지다른 노드의 파드끼리 데이터 공유는 안됨 (주로 노드 로그 모니터링 용도)hostPath 사용 현황 파악

데이터가 지속모든 파드에서 공유mongo 컨테이너에 마운트하여 사용GCE 영구 디스트를 동일한 리전에 생성 gcloud compute disks create --size=10GiB --zone=us-central1-a mongodb파드 YAML의 gcePersisten

파드 개발자가 클러스터에서 스토리지를 사용할 때 인프라를 알아야 하는지..실제 네트워크 스토리지를 사용하려면 알아야 함.애플리케이션 배포하는 개발자가 스토리지 기술의 종류를 몰라도 상관없도록 하는 것이 이상적인프라 관련 처리는 클러스터 관리자의 유일한 도메인pv와 pv

PV를 직접 만드는 대신 사용자가 원하는 PV 유형을 선택하도록 오브젝트를 정의하는 기능storageclass.yamlmongodb-pvc.yamlkubectl delete pods mongodbkubectl replace -f mongodb-pvc.yaml --for

쿠버네티스의 환경 변수는 YAML 파일이나 다른 리소스로 전달하드 코딩된 환경 변수는 여러 환경에 데이터를 정의하거나 유지, 관리가 어려움ConfigMap를 통해 외부에 컨테이너 설정을 저장할 수 있음node-env.yaml kubectl create configmap

CPU와 메모리는 집합적으로 컴퓨팅 리소스 또는 리소스로 부름CPU 및 메모리는 각각 자원 유형을 지니며 자원 유형에는 기본 단위를 사용리소스 요청 설정 방법리소스 제한 설정 방법

Replication Controller와 ReplicaSet은 무작위 노드에 포드를 생성데몬셋은 각 노드마다 하나의 포드를 생성대표적으로 kube-proxy가 데몬셋으로 구성됨사용 예시로, 로그를 수집할 때 사용할 수 있음 (파드에서 hostPath로 로그를 마운트

| Effect 종류 | 설명 | |------------------|---------------------------------------------------

temp.yamlRemove the taint on controlplane, which currently has the taint effect of NoSchedule.What is the state of the pod mosquito now?

특수한 환경의 경우 특정 노드에서 실행되도록 포드를 제한일반적으로 스케줄러는 합리적인 노드에 자동으로 포드 배치를 수행하므로 이러한 제한은 필요하지 않음더 많은 제어가 필요할 수 있는 몇 가지 케이스SSD가 있는 노드에서 포드를 실행하기 위한 경우블록체인이나 딥러닝 시

기본 스케줄러가 사용자의 필요에 맞지 않으면 사용자 고유의 스케줄러 구현 가능기본 스케줄러와 함께 여러 스케줄러를 동시에 실행 가능각 포드에 사용할 스케줄러를 지정하는 방식도 가능my-scheduler.yaml

오토바이의 사이드카에서 유래이륜차에 기존 기능을 향상/확장하는데 사용 (여기서는 파드의 기능을 향상)파드의 파일시스템을 공유하는 형태접속 후 다음 명령을 통해 로그 확인kubectl logs nginx-sidecar sidecar-access

쿠버네티스 클러스터를 운영할 때 일정 주기마다 돌아가야 하는 작업들이 존재넷플릭스가 2013년에 공개한 아키텍처개인에게 맞춤 추천 시스템을 사용하기에는 너무 많은 리소스가 필요하기 때문에 넷플릭스의 추천 시스템은 실시간 (OnLine) 분석, 준 실시간 (Nearlin

크롭잡은 반복 일정에 따라 잡 (완료를 목표로 실행되는 유한 또는 배치 작업)을 생성한다.예약 시간 작성 요령기존 리눅스 시스템의 크론에서 표기하는 방법과 동일CronJob yaml 파일에는 예약 실행할 시간과 실행할 컨테이너를 작성일반적으로 CronJob 하나에 하나

Helm은 쿠버네티스 애플리케이션 관리를 지원하는 도구복잡한 쿠버네티스 애플리케이션을 정의, 설치, 업그레이드하는 데 도움사용자는 복잡한 구조의 애플리케이션을 직접 구성하는 대신 helm에 정의되어있는 내용을 사용해 쉽게 설치하거나 삭제할 수 있음Helm은 CNCF의

helm은 외부에서 정의된 yaml 파일을 내려 받아 쿠버네티스에 애플리케이션을 배포apt, yum과 같이 저장소를 별도로 두고 있음이 외부 저장소를 helm repo add 명령으로 추가다음 명령을 실행해 bitnami 저장소를 helm 목록에 추가한 뒤 업데이트 진

쿠버네티스를 지원하는 다양한 모니터링 플랫폼쿠버네티스의 메트릭 수집 모니터링 아키텍처에서 코어 메트릭 파이프라인 경랭화힙스터를 deprecated 하고 모니터링 표준으로 메트릭 서버 (metrics-server) 도입쿠버네티스 클러스터 내의 애플리케이션 성능을 검사쿠버

인증서와 키가 없다면 다음 두 가지 주요 방법 중 하나를 선택하여 인증서를 얻을 수 있습니다:무료 인증서 발급 (Let's Encrypt): Let's Encrypt는 무료로 인증서를 발급하는 인증 기관(CA)입니다. cert-manager와 같은 Kubernetes

로그는 컨테이너 단위로 로그 확인 가능싱글 컨테이너 포드의 경우 포드까지만 지정하여 로그 확인멀티 컨테이너의 경우 포드 뒤에 컨테이너 이름까지 전달하여 로그 확인\`kubectl logs <옵션: container name>쿠버네티스에서 돌아가는 리소스들은 모두

다수의 컨테이너가 동작하는 경우에는 각 컨테이너의 트래픽을 관찰하고 정상 동작하는지 모니터링하기가 어렵기 때문에 DevOps 팀에 부담개발자는 이식성을 위해 마이크로서비스를 사용하여 아키텍처를 설계하고 운영자는 이 컨테이너들을 다양한 클러스터에 배포하고 관리서비스 메시

쿠버네티스에서 EFK를 사용하면 도커의 각 컨테이너 로그를 수집하고 시각화, 분석 가능쿠버네티스 메모리 8GB 이상 필요엘라스틱 스택은 주로 비츠나 로그스태시를 사용하는 것이 일반적쿠버네티스에서는 fluentd를 사용해서 수집하는 것이 유행E: Elasticsearch

다수의 컨테이너가 동작하는 경우, 각 컨테이너의 트래픽을 관찰하고 정상 동작하는지 모니터링하기 어려움서비스 메시의 크기와 복잡성이 커짐에 따라 관리에 어려움 생김Istio는 이러한 쿠버네티스 환경의 네트워크 메시 이슈를 보다 간편하게 해결하기 위해 지원하는 환경서비스

모든 통신은 TLS로 대부분의 액세스는 kube-apiserver를 통하지 않고 불가능엑세스 가능한 유저X509 Client Certs -> 쿠버네티스 클러스터 직접 구축했을 때 썼던 토큰Static Token FilePutting a Bearer Token in a

유저: 일반 사용자 (개발자 또는 데브옵스 엔지니어)를 위한 계정서비스어카운트: 애플리케이션(파드 등)을 위한 계정Apiserver 서비스를 실행할 때 --token-auth-file=SOMEFILE.csv 전달 (kube-apiserver 수정 필요)API 서버를 다