🖥️제로부터 시작하는 Docker & 쿠버네티스

clear : 명령어들 클리어whoami : 자신의 아이디 확인 sudo apt-get update : 루트사용자 권한으로 모든 파일 업데이트pwd : 현재 경로 확인cd : 파일 이동ex) ubuntu/ : 다음 폴더인 ubuntu경로로 이동ls : 해당 디렉토리에

리눅스 쉘 연습리눅스 쉘 스크립트를 연습하려하니 putty를 통해 세션을 연결하고, 우분투 서버에 연결하는게 귀찮게 느껴졌다.그러다 다양한 명령어들을 입력할 수 있는 연습 사이트를 찾았다.실제 서버와 완전 똑같은 환경도 아니고, 실제 서버와 버전 차이로 인한 명령어 차

https://docs.docker.com/engine/install/ubuntu/에 접속해서기존에 설치한 서버에 해당 웹페이지에 있는 명령어를 실행하여 도커를 설치한다.위 윕페이지내에서 도커가 정상 설치되었는지 확인하는 명령어가 있다.Verify that t

도커 명령어는 CLI로 입력하는 형태.이 명령어를 통해 도커가 제대로 설치 되었는지 확인한다.위 명령어를 통해 docker의 상태를 조회할 수 있다.서비스가 활성(active)인지, 비활성(inactive)인지, 실패(failed)인지 확인할 수 있다.(이후에 명령어를

"런타임 의존성과 함께 애플리케이션을 패키징하는 기술"컨테이너에 대한 설명에 이렇게 나와있다. 이 말만 들어선 의미가 잘 와닿지 않는데, 런타임 의존성이란 애플리케이션이 실행될 때(런타임 시점) 정상적으로 동작하기 위해 함께 있어야 하는 외부 소프트웨어 구성요소들이다.

쿠버네티스 개념을 공부할때마다 나오는 pod가 대체 무엇인지 모르겠어서, 쿠버네티스의 개념과 구성요소를 이해하기 전에 먼저 이해하도록 한다. 쿠버네티스에서 가장 작은 배포 단위는 컨테이너가 아니라 Pod다. Pod는 하나 이상의 컨테이너를 포함할 수 있다.Pod의 콘텐

출처 : CNF - 쿠버네티스 아키텍처 완벽 가이드 : 구조와 동작 원리 A to Zhttps://www.cncf.co.kr/resource/kubernetes-architecture-guide/이 순서는 쿠버네티스가 단순한 컨테이너를 실행하는 것 뿐만 아니라

# 쿠버네티스 배포 프로세스 공식문서에는 이렇게 쿠버네티스의 배포에 대해 이렇게 나와있다. - "쿠버네티스의 배포는 애플리케이션 워크로드를 실행하기 위해 여러 파드를 관리하며 보통 stateless 애플리케이션을 대상으로 한다." -> 이 말은 즉, 파드가 언제 죽

CNI(Container Network Interface) 는 컨테이너의 네트워크를 구성하고 관리하기 위한 표준 인터페이스이다.명령으로 파드를 생성하면, 몇 초 안에 그 파드는 고유한 IP를 부여받고 클러스터 내 다른 파드들과 통신할 수 있게 된다.이러한 IP 할당과

전 게시물을 통해서 CNI라는 것을 통해 표준 네트워크 인터페이스 덕분에 네트워킹 솔루션을 사용할 수 있게 되었다.이 게시물에서는 가장 많이 사용되고 있는 CNI도구 중 Calico, Cilium, Flannel에 대해 다루려한다.Calico는 대규모 확장성에 초점을

쿠버네티스와 DNS 할당 방법 쿠버네티스는 파드와 서비스를 위한 DNS 레코드를 생성한다. 사용자는 DNS를 통해 IP대신 DNS를 통해 서비스에 접속할 수 있다. 쿠버네티스는 DNS를 설정하기 위해 사용되는 파드와 서비스에 대하 정보를 발행한다. kubelet은 실

IP주소나 포트 수준(OSI 3,4 계층)에서 트래픽 흐름을 제어하기 위한 보안 메커니즘이다. 이를 통해 클러스터 내부 뿐만 아니라 Pod와 외부 간 트래픽 흐름 규칙을 지정할 수 있다.TCP, UDP, SCTP 등의 프로토콜에 대해 IP 주소 및 포트 단위로 접근을

모든 파드는 고유한 IP를 가지지만, 파드가 재시작되거나 다른 노드로 옮겨갈 때마다 이 IP가 변경되는 비영속적인 특성을 가지고 있다. ->즉, 파드는 고정된 IP를 가지지 않기 때문에, 이렇게 수시로 바뀌는 파드들의 IP를 일일이 추적하고 관리하는 것은 현실적으로 어

쿠버네티스 스케줄러란 kubelet이 파드를 실행할 수 있도록, 파드가 노드에 적합한지 확인하는 것을 말한다.kube-scheduler는 쿠버네티스의 기본 스케줄러로, 컨트롤 플레인의 일부로 동작한다.새로 생성되었거나 아직 어떤 노드에도 배치되지 않은 파드에 대해, 가

컨테이너 내부 디스크에 저장된 파일은 임시적이다.즉, 컨테이너가 재시작되면 그 안의 데이터는 모두 사라진다.이로 인해 애플리케이션이 실행될 때 몇 가지 문제가 생길 수 있다.컨테이너가 크래시될 때 파일이 손상된다는 것 (kubelet이 컨테이너를 다시 시작하지만, 초기

도커 데스크탑 maxOS 버전 설치 후setting에 들어가서 kubernetes를 누르면 알아서 쿠버네티스를 내려받아 단일 노드 클러스터를 실행해준다.이 과정에서 자동으로 쿠버네티스 런타임에 필요한 모든 컨테이너 이미지를 내려받아준다.아주 편리한 기능이다.쿠버네티스는

컨테이너가 컨테이너를 실행하고 관리하기 전 게시글에서 파드는 대게 컨테이너 하나를 포함하는데, 설정에 따라 파드 하나가 여러개의 컨테이너를 포함하고 , 파드에 포함된 모든 컨테이너는 같은 가상환경에 포함된다. 각각 파드에는 IP 주소가 부여되는데, 파드에 포함된

### k8s_env_build.sh — 쿠버네티스 환경 구성 이 스크립트는 쿠버네티스 설치를 위한 기본 시스템 환경을 설정하는 스크립트이다. - swap 비활성화 (swapoff -a) - 방화벽 설정 (필요 시 포트 열기) - 네트워크 구성 (br_netfilte

Vagrant 2.4.7 (다운그레이드 버전)→ 호환성 문제 때문에 최신 2.4.9 대신 2.4.7 사용VirtualBox 7.1.10→ Vagrant 2.4.7과 호환 가능한 버전Tabby (v1.0.207)→ 각 VM에 SSH 접속용 터미널Vagrant 설정 파일(

현재 생성된 파드 정보들 \*전부 출력 hello-docker라는 이름을 가진 파드에 대한 정보 출력이와 같이 출력하면 다음과 같이 나온다. \--output=custom-columns: 원하는 열(column)을 직접 지정해 출력하는 옵션"NAME:.metadata.

쿠버네티스를 공부하다 보니 쿠버네티스, 파드, 도커, 컨테이너, 클러스터, kubelet의 관계에 대해 혼동이 오기 시작했다. 그래서 이 포스팅으로 한번에 정리해보려고 한다. 우리는 일단 “쿠버네티스는 파드를 관리한다”라는 말을 정말 자주 듣게 된다. 그런데 막상

쿠버네티스에서는 kubectl 명령어를 통해 클러스터 내부의 리소스를 직접 제어할 수 있다.아래는 가장 많이 사용되는 명령어들을 간단히 실습해본 예시이다.위는 해당 명령어들을 사용해 본 예제이다.\-> 위 명령어는 nginx 파드를 3개로 늘린다.\-> 위 명령어를 실

이번 게시물에서는 디플로이먼트를 생성하고 디플로이먼트가 관리하는 파드에 레이블을 부여하는 실습을 진행한다.그 전에 컨트롤러, 디플로이먼트의 개념을 먼저 정리한다. 쿠버네티스에서 Pod는 가장 기본적인 실행 단위이며 Pod안에 있는 컨테이너의 명세대로 실행하는 것은 ku

apiVersionbatch/v1 — 잡 관련 리소스는 batch API 그룹에 포함된다.kind리소스의 종류를 지정한다. 여기서는 CronJob.metadata.name리소스의 이름이다. (hello-cron)spec.schedule실행 주기를 지정한다. (cront

데몬셋(DaemonSet) 데몬셋은 쿠버네티스에서 모든 노드(혹은 특정 노드)에 파드를 하나씩 자동으로 배포하는 리소스이다. ex) 로그 수집가, 모니터링 에이전트같은 시스템성 파드들 코드 해설 >| 항목 | 설명

StatefulSet은 말 그대로“상태(State)를 가진 파드를 순서대로 생성·유지하는 컨트롤러”이다.Deployment는 파드를 아무 순서나 생성·삭제하지만,StatefulSet은 순서를 엄격히 지킨다.예를 들어, 생성 순서 → pod-0 → pod-1 → pod-

쿠버네티스에서 포트포워딩이란, 로컬 PC의 포트를 클러스터 내부 파든의 포트로 직접 연결해주는 기능이다.즉, 클러스터 안에 있는 파드에 직접 접근할 수 있도록 해주는 것이다.ex) nginx 파드가 내부에서 80포트를 사용중이라면, 내 PC의 8080 포트를 파드의 8

쿠버네티스의 Service 타입 중 LoadBalancer는클러스터 외부에서 접근 가능한 IP(External IP)를 자동으로 할당해주는 방식이다.일반적으로 AWS, GCP, Azure 같은 클라우드 환경에서는LoadBalancer 타입을 설정하면 클라우드 로드밸런서

쿠버네티스의 Service 타입 중 하나인 ExternalName은 클러스터 밖에 있는 서버를 내부 서비스처럼 부를 수 있게 해주는 기능이다. 예를 들어, 내 쿠버네티스 안의 애플리케이션이 외부 DB 서버(db.company.com)에 접근해야 한다면, 굳이 매번 그

클러스터 IP란 쿠버네티스에서 Service 타입 중 기본값인 ClustIP가 가지는 내부 전용 IP를 말한다.이게 기본 정의인데, 쉽게 풀어쓰자면"클러스터 안에서만 접근 가능한 내부 IP주소"이다.예를 들어 이렇게 service를 호출했을 때 ,이런식으로 나온다.여기

이 게시물에서는 많은 볼륨 종류 중 빈 디렉토리에 대해 알아보려고 한다.이 볼륨은 파드가 노드에 할당될 때 처음 생성되며, 해당 노드에서 파드가 실행되는 동안에만 존재한다.이름에서 알 수 있듯 처음에는 비어있다.모든 컨테이너가 같은 디렉토리를 공유해서 사용할 수 있다.

이번 게시물은 호스트에 있는 디렉토리를 파드가 쓰는 hostpath에 대해 작성했다. 다만, 쿠버네티스 공식 문서에서도 아래처럼 여러 차례 경고하듯이,hostPath는 매우 강력하지만 신중히 사용해야 하는 기능이다.파드가 호스트 파일 시스템에 직접 접근하거나 수정할 수

이번에는 네트워크로 연결할 수 있는 공유 파일 시스템같은 역할인 nfs 볼륨에 대해 적어보려 한다.nfs 볼륨을 사용하면 기존 NFS(네트워크 파일 시스템) 볼륨을 파드에 마운트할 수 있다. NFS는 여러 작성자가 동시에 마운트할 수 있다. emptyDir와 달리 파드

이전 포스팅에서 PV(퍼시스턴트 볼륨)과 PVC(퍼시스턴트 볼륨 클레임)의 개념에 대해 설명하였다.이전 포스팅 (PV, PVC 개념 정리)또한 바로 이전 포스팅에서 nfs 볼륨을 만드는 실습을 진행하였다. 이번 포스팅에서는 관리자가 생성하는 PV(PersistentVo

이번에 올릴 게시물은 이전 게시물(pv, pvc 생성)에서 정적 pv/pvc를 생성했던 것ㄹ과 달리, StorageClass를 이용해 PVC가 자동으로 PV를 생성하는 구조를 만들어본다.파일명: rbac.yamlNFS 프로비저너가 쿠버네티스 리소스(PV, PVC)를 자

volumeClaimTemplates는 StatefulSet에서 “파드마다 따로 PVC를 자동으로 만들어주는 템플릿” 이다.일반 Deployment:보통 하나의 PVC를 여러 파드가 같이 쓰거나, 아예 PVC 없이 emptyDir 같은 거 씀.StatefulSet +

이번 벨로그 글은 “Node cordon & drain 실습”을 주제로,노드 하나를 스케줄 불가로 만들고(cordon),파드를 안전하게 내보내는(drain) 실습 중심으로 구성된다.Deployment로 replica=3짜리 NGINX 파드를 배포함클러스터에는 노드가 3

이번 게시물에서는 노드 네임, label, 노드 셀렉터를 사용하는 것을 진행해보겠다.현재 노드 구성과 레이블이 이렇게 되어있는데 노드에 레이블을 붙일 수 있다.env, region은 키값이며 dev, stage, shared, internal은 각각 value에 해당한

현재 노드 구성과 레이블이 이렇게 되어있는 상태이다.파일명: deploy-affinity.yamlrequiredDuringSchedulingIgnoredDuringExecution: 반드시 이 조건을 만족하는 노드에만 스케줄됨따라서, env=dev 라벨이 있는 mult

쿠버네티스에서 Node Affinity가 “특정 노드에 끌림”이라면,Taints(테인트)는 반대로 “특정 노드가 거부”하는 개념이다.여기에 Tolerations(톨러레이션)은 “그 거부 조건을 허용하는 예외권”을 의미한다.노드에 taint 설정 방법taint 삭제Pod

파드 레이블 create 해서 만들었을 때랑 (app = ""형식) run 해서 파드를 만들었을 때랑 붙는 레이블이 다르다. (run= ""형식)

쿠버네티스를 공부하다가 갑자기 정적(static) 파드에 대해 뜬금없이 나와서 이게 무엇이고, 왜 중요한건지 헷갈렸다. 특히 스케줄러가 파드를 관리하고 배포한다고 했다가, 스케줄러 또한 파드인데그것은 누가 띄우는 건지 의문이 생겨서 정리해보기로 했다.일반적으로 우리가

restartPolicy는 파드(Pod)의 사양(spec) 중 하나로, 컨테이너가 종료되었을 때 쿠버네티스가 어떻게 동작할지를 정의하는 옵션이다.공식문서 기준으로 가능한 값은 다음 세가지이다. 여기서 restartPolicy는 spec 바로 아래에 들어간다.컨테이너와는

쿠버네티스에서는 컨테이너가 단순히 “running”이라는 상태만으로는 충분히 완벽하게 서비스가 실행된다고 생각하지 않는다.그래서 다음과 같은 세 가지 탐사(probe) 를 사용한다:startupProbe: 컨테이너가 ‘정상적으로 시작했는가’를 검사한다.livenessP

쿠버네티스를 공부하다 보니까 initContainers 라는 게 갑자기 튀어나온다.처음엔 “그냥 컨테이너 하나 더 넣는 건가?” 싶었는데,언제 실행되는지, 왜 굳이 따로 분리해 놨는지 헷갈려서 한 번 정리해보기로 했다.보통 애플리케이션 파드에 이런 작업들이 필요해질 때

하나의 Pod 안에 여러 컨테이너를 넣는 이유는 보통 앱 코드 건드리지 않고 기능을 붙이고 싶어서이다.쿠버네티스 공식 블로그에서도 대표적인 패턴으로 Sidecar / Ambassador / Adapter 패턴을 소개하고 있다.모두 하나의 Pod안에서 메인 컨테이너를 도

공식 문서에서는 Pod Topology Spread Constraints 를"파드를 리전, 존, 노드 같은 장애 도메인(failure-domain)에 고르게 분산시키기 위한 방법"이라고 설명한다.쉽게 말하면, “app=nginx 인 파드들은 각 AZ(또는 노드)에

쿠버네티스에서 리소스들은 모두 네임스페이스(namespace) 단위로 구분되어 관리된다.즉, 하나의 클러스터 안에서도 여러 팀이나 프로젝트가 겹치지 않게 독립된 공간을 사용하는 개념이다.예를 들어dev1 팀은 자신들의 파드, 서비스, 디플로이먼트를 관리하고dev2 팀은

한 마디로 리소스 쿼터란 네임스페이스별 사용량 제한 제도이다.에서쿠버네티스 클러스터가 회사 본사,각 네임스페이스가 팀(부서) 라고 비유를 들었는데, 여기에서 리소스 쿼터는 이런 느낌이다.“dev1 CPU 너무 많이 쓰지 말고,메모리도 4GB까지만 써.”“dev2팀은 파

한 마디로 리밋 레인지(LimitRange) 는“네임스페이스 안의 각 파드나 컨테이너별 자원 사용 한도와 기본값을 지정하는 제도”이다.이전 게시물 : 리소스 쿼터(ResourceQuota)에서리소스 쿼터가 “네임스페이스 전체 팀 단위로 예산(총량)을 정하는 것”이었다면

쿠버네티스를 처음 쓰면, 파드끼리 서로 다 통신 가능하다.default 네임스페이스든, 다른 네임스페이스든, 아무 제약 없이 서로 TCP/UDP 통신이 된다.공식 문서에서는 NetworkPolicy를“파드가 서로, 그리고 다른 네트워크 엔드포인트와 어떻게 통신할 수 있

쿠버네티스 공식 문서에서는 ConfigMap 을 이렇게 정의한다.“기밀이 아닌 설정 데이터를 key-value 형태로 저장하는 API 오브젝트이며,파드에서 환경변수, 커맨드 인자, 볼륨 파일로 소비할 수 있다.”한 마디로,이미지 안에 두기 애매한 설정값들을 따로 뽑아놓

쿠버네티스 시크릿(Secret)은비밀번호, 토큰, 인증서 키처럼 민감한 데이터를 저장하기 위한 API 오브젝트이다.컨테이너 이미지나 파드 매니페스트 안에 비밀번호를 그대로 적어두면,깃 저장소에 그대로 올라가고CI/CD 로그나 kubectl describe 출력에도 노출

롤링 업데이트란 쿠버네티스에서 Deployment/StatefulSet의 기본 업데이트 전략이 롤링 업데이트이다.공식 문서 기준으로 보면 롤링 업데이트는기존 파드를 한 번에 전부 죽이지 않고,새 버전 파드를 조금씩 띄우고, 옛날 파드를 조금씩 내리면서서비스 중단 없이

Kustomize는 쿠버네티스 리소스를 템플릿 없이 덧입혀서(overlays) 관리하기 위한 도구이다.요즘은 kubectl 안에 통합되어 있어서 별도 설치 없이 kubectl kustomize, kubectl apply -k 같은 식으로 바로 쓴다.핵심 아이디어:디렉터

공식 문서 기준으로 헬름은“쿠버네티스 애플리케이션을 정의·설치·업그레이드하는 패키지 매니저”이다.쿠버네티스로 뭔가를 배포하려고 하면 보통:Deployment, Service, ConfigMap, Secret, Ingress …이런 YAML 파일이 최소 수십 개씩 생긴다

버네티스에서 kubectl top 이나 HPA(오토스케일러)가 쓰는CPU / 메모리 실시간 사용량을 모아서 제공해주는 컴포넌트이다.동작 흐름은 다음과 같다.각 노드의 kubelet 이 파드 / 노드의 리소스 사용량을 노출한다.metrics-server가 주기적으로 ku

HPA는 파드 개수를 자동으로 늘렸다 줄였다 해주는 컨트롤러이다.보통 CPU 사용량이나 메모리 사용량, 혹은 커스텀 메트릭을 기준으로 스케일링한다.동작 흐름은 대략 이렇다.metrics-server 가 각 파드/노드의 CPU·메모리 사용량을 모은다.HPA 컨트롤러가 m

헬름 설치하기 일단 프로메테우스를 설치하는데, 헬름이 설치되어 있지 않아서(helm version 했을 때 찾을 수 없었다.) 위 명령어를 통해 헬름을 설치해줬다. 프로메테우스 설치 위 명령어를 실행하여 프로메테우스를 설치해준다. 프로메테우스 설치 확인

이전 게시물에서 vmware fusion으로 실습 환경 구축하다가 트러블슈팅만 삼일 동안 꼬박 밤새서 하고 50번 이상 지웠다 깔았다를 반복하다가 결국 전부 삭제 후, 강사님이 올려주신 vagrantfile로 vagrant up을 하여 성공적으로 실습 환경을 구축하였다

프로메테우스 Web UI Runtime & Building information Status에서 해당 메뉴로 들어가게 되면 다음과 같이 나온다. 여기에서 중요한 부분은 build information에 있는 version 부분인데, 현재 내가 쓰고 있는 버전은 2

cAdvisor(Container Advisor)는 쿠버네티스 노드에서 컨테이너의 리소스 사용량을 수집하는 모니터링 도구이다.도커 엔진에 기본 내장되어 있으며, CPU∙메모리∙네트워크∙디스크 I/O 같은 컨테이너 단위 메트릭을 자동으로 수집한다.쿠버네티스에서는 kube

쿠버네티스를 모니터링할 때 흔히 Node Exporter나 cAdvisor로 CPU·메모리 같은 리소스 데이터를 수집한다. 이전 게시물(cAdvisor, Node Exporter 설명)근데 이 둘은 공통점이 있는데, "실제 사용량"만 알려주며, kubernetes 객체

쿠버네티스에서 Node Exporter, cAdvisor를 통해 노드/컨테이너 리소스는 잘 수집하고 있다. 근데 서비스 운영하다 보면 이런 의문이 생긴다. “애플리케이션 자체의 지표는 어떻게 보지?” 예를 들어, NGINX가 현재 처리 중인 HTTP 연결 수 요청

Prometheus를 쓰다 보면 가장 많이 마주치는 개념이 바로 메트릭 타입이다.메트릭 타입을 정확히 이해해야 올바른 모니터링과 알람 설정이 가능하다.Prometheus에는 총 4가지 메트릭 타입이 있다.GaugeCounterHistogramSummary이 글에서는 각

PromQL에서도 숫자끼리 더하고 빼고 비교 가능하다.메트릭을 합치거나 평균내는 기능이며,PromQL에서 제일 많이 쓰는 기능이다.ex: 파드 개수 세기→ 현재 시점의 값 한 개업로드중..→ 시간 구간을 포함한 여러 샘플

PromQL에서 메트릭을 선택하거나 매칭할 때 사용됨.PromQL은 함수를 많이 제공한다.자주 쓰는 함수:ex)

Recording Rule은 Prometheus에서 자주 사용하는 계산식(PromQL) 을미리 계산해 새로운 메트릭으로 저장해두는 기능이다.이렇게 해두면,무거운 쿼리 계산이 빨라지고UI에서도 즉시 조회가 가능하며자주 쓰는 식을 “메트릭처럼” 편하게 사용할 수 있다.예를

이번 포스팅에서는 Kubernetes 환경에서 Redis 메트릭을 Prometheus로 수집하는 방법을 정리한다.Prometheus는 기본적으로 애플리케이션 내부 상태는 알 수 없기 때문에,Redis 내부 정보를 가져오려면 Redis Exporter가 필요하다.이번 실

MySQL + mysqld-exporter 구성하기 쿠버네티스 환경에서 MySQL을 모니터링하려면 Prometheus가 읽을 수 있는 형태의 메트릭을 노출해야 한다. MySQL 자체는 메트릭을 제공하지 않기 때문에 mysqld-exporter를 추가로 배포해야 한다

Blackbox Exporter는 애플리케이션 내부 메트릭을 수집하는 방식이 아니라,외부에서 특정 엔드포인트에 실제 요청을 보내어 정상 동작 여부를 확인하는 모니터링 도구이다.즉, 시스템 내부 상태가 아니라 “외부에서 바라본 서비스의 응답 상태”를 측정한다.Blackb

Prometheus로 메트릭을 수집하는 방법이 여러 가지가 있다 보니 프로메테우스 설정을 하면서 순간적으로 헷갈리는 부분이 많았다.특히, Exporter를 직접 구성해서 ServiceMonitor로 연결하는 방식과 Helm Chart로 자동 구성하는 방식의 차이가 명확

공부하다보니 service monitor와 pod monitor에 대한 개념이 빈약하다고 느껴 정리를 해야겠다는 생각이 들었다. 각 개념을 설명하고 두 모니터의 차이를 비교해서 적을 것이다.PodMonitor는 “파드 자체를 직접 선택해서(PodSelector)” 메트

모종의 사유로 인해 Helm으로 Prometheus를 다시 구축하게 되었다.그 후 Prometheus UI에 접속하기 위해 Node IP + Prometheus 서버 포트로 접속을 시도했는데, 접속이 전혀 되지 않았다.포트 포워딩까지 해보며 http://loc

왜 이 글을 쓰게 되었는지 쿠버네티스 실습 중 Prometheus를 사용해 외부 서비스의 메트릭을 수집하는 구조를 이해하기 위해 이 실습을 진행했다. 특히, 쿠버네티스 클러스터 내부가 아닌 외부 VM에서 동작하는 Harbor의 메트릭을 Prometheus가 수집하는

현재 이렇게 pods와 service는 모두 올라온 상태이다.따라서http://192.168.1.12 에 접속하게 되면 다음과 같이 확인할 수 있다.Grafana의 역할은 다음과 같다.혼자서는 아무것도 못 한다반드시 데이터 소스(Data Source) 가 필요

이번 포스팅에는 그라파나 대시보드에서 pie chart 및 state timeline, heatmap 등 대시보드를 다양하게 만들어보려고 한다.이렇게 대시보드에 처음 들어가면 아무것도 없다.여기서 패널을 추가하고, 워커노드별 cpu 사용율을 pie chart로 보기 위

이번 게시물에서는 그라파나 대시보드에서 apiserver 요청에 대한 응답시간 (시간 흐름)을 heatmap을 만들어보려고 한다.우선 를 쿼리하여 데이터가 나오는지 확인해본다.이제 여기에 sum을하고 1m에 대해 less then equal로 group by하여 쿼리한

이번 게시물에서는 Grafana 대시보드에서 Dashboard > New panel을 통해 Histogram 시각화를 직접 만들어보는 과정을 정리해본다.목표는 Kubernetes API Server 요청 처리 시간의 분포를 히스토그램으로 확인하는 것이다.우선, 데이터가

리눅스는 크게 Debian 계열과 Red Hat 계열로 나눌 수 있다.이 구분은 무료/유료의 문제가 아니라, 패키지 관리 방식과 배포 정책의 계열 차이이다.Debian 계열은 apt, dpkg 기반의 패키지 관리 방식을 사용한다.Red Hat 계열은 rpm, dnf(y

컨테이너가 등장하기 전의 배포 방식은 비교적 단순한 구조였다.애플리케이션을 빌드해서 나온 실행 파일을 서버에 복사하고 실행하는 방식이다.개발자는 IntelliJ 같은 IDE를 사용해 코드를 작성한다.개발이 완료되면 Gradle 같은 빌드 도구를 통해 빌드를 수행한다.빌

그동안은 쿠버네티스 환경을 구성할 때 강사님께서 주시는 vagrantfile을 그저 받아서 vagrant up을 하여 설치환경을 구성하였는데, 이제는 단순한 실습 환경을 넘어서,인프라 관리자의 관점에서 쿠버네티스를 어떻게 설치해야 하는지를공식 문서를 기준으로 하나씩 확