쿠버네티스

Docker를 공부할 때에도 사실 잘 이해를 못 했었다.와닿지 않았달까..,?그런데! Kubernetes로 서비스를 직접 배포해보면서 깨달았다!!! Container의 폭력성그래서 공부하면서 애매했거나, 이해하기 어려웠던 부분 위주로 적어 둘 생각이다.공부한 걸 보는데

1\. Loosely coupled (느슨한 결합) & High-cohesion (높은 응집력)2\. Bounded context (결정 경계)  하나의 서비스가 변경될 때 다른 서비스가 변경되는 일이 없음 시스템의 그 어떤 부분도 추가 변경할 필요 없이 특정 서비스를

쿠버네티스 애플리케이션의 기본 실행 단위 (만들고 배포할 수 있는 가장 작은 단위)Docker는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임.파드는 다른 컨테이너 런타임도 지원. (rtk, containerd)파드당 컨테이너 비율은 대체로 1:1. (예외

라벨은 파드뿐 아니라 쿠버네티스의 모든 리소스를 구성하는 간단하고 강력한 기리소스에 부여하는 임의의 Key/Value 쌍라벨 셀렉터를 사용해 리소스를 선택할 때 사용일반적으로 리소스를 만들 때 부여하지만, 이후에도 라벨을 추가 혹은 변경 가능필터링에 사용. (라벨의 개

Docker Container를 사용해 로컬 K8S Cluster 실행을 위한 도구K8S 테스트 도구로 많이 사용Window를 기준으로 작성. ⇒ kind-windows-amd64.exe → kind.exe로 이름 변경  3-node-cluster.yaml→ 80 Po

K8S는 liveness Probe를 통해 컨테이너의 Health Check를 수행Health Check가 실패할 경우, POD를 다시 시작 HTTP GET : 지정된 IP/PORT에 HTTP GET을 수행TCP Socket : 지정된 IP/PORT에 TCP 연결을 수

Deployment는 Pod 와 ReplicaSet 에 대한 선언적 업데이트 제공하며, 배포에 대한 세분화된 기능 제공Deployment 에 의도하는 상태를 기술하면, Deployment Controller는 현재 상태에서 의도하는 상태로 비율을 조정Pod 에 대한 롤

파드들을 통해 실행되고 있는 애플리케이션을 네트워크에 노출시키는 가상의 컴포넌트파드들은 언제든 다른 노드로 옮겨지거나 삭제될 수 있고새로 생성될 때 마다 새로운 내부 IP를 받게 되므로 내/외부 통신을 유지하기 어려움→ 파드가 외부와 통신할 수 있도록 클러스터 내부에서

Pod에서 실제 데이터가 있는 디렉토리를 보존하기 위해 사용Pod의 일부로 정의 되며, Pod와 LifeCycle을 같이함독립적인 쿠버네티스 오브젝트가 아니며, 스스로 생성 하거나 삭제할 수 없음 (Kind X)마운트(mount)를 통해서만 사용할 수 있다.실제 호스트

ConfigMap 및 Secret 는 Key Value 쌍으로 데이터를 저장 하는 점에서는 동일 • ConfigMap은 일반적인 USE CASES• 환경 변수 및 파라매터 전달• Container 내부에서 사용되는 명령어 및 매개 변수• 어플리케이션이 사용하는 읽기 전

나는 주로 AWS의 EKS를 사용했고, 온프레미스에서 사용할 때에는 kubespary를 사용했다. > 이번에 OpenStack을 사용하면서 ubuntu 24.04를 사용해야 한다. 그래서 kubeadm을 이용해 cluster를 구축해보려 한다. 0. 전제 조건 u

현재 OpenStack의 구조가 다음과 같다.Ingress를 LoadBalancer로 하자니 Public IP의 포트가 1000o으로 제한되어 있어 안된다.NodePort로 하자니 마찬가지로 30000~ 이상의 포트를 지정할 수 없어서 안된다.그래서 결정한 방법은 아래

calico node pod가 Running이지만 0/1, 실행 되지 않은 상태였다.  calico-node가 인터페이스를 통해 통신이 불가능 하기 때문에 발생한다.  보안 그룹에 Port 179를 추가해야 한다.BGP를 통해 통신하는데, BGP Port가 막혀있었던

defaultBackend : rule이 매칭되지 않은 트래픽은 defaultBackend로 라우팅      온프레미스에 클러스터 구성 시 , 로드밸런서 타입은 externel IP가 없어 pending 상태일 것이다.MetalLB를 사용해 로드밸런서를 구성해야 한다.

리소스 사용량 확인을 위해 metric-server를 설치했다.그런데 error: Metrics API not available 로 실행되지 않는다.      수정 후에도 kubectl top no와 같이 top 명령어 사용 시 에러 발생.  원인은 metric-ser

OpenStack에서 구축한 클러스터에 React 및 Express로 구현한 웹 서비스를 배포했다.NodePort로 접속 시, 접속이 되지 않고 무한 로딩이 걸렸다.Nginx Log를 확인해보니, 110 connection timed out 오류 였다.   노드의 DN

항상 kubectl \~~ 를 열심히 사용해 왔다.그런데 인터넷을 보면 다른 사람들은 k \~~ 를 사용하는 것이 아닌가!??그래서 나도 해보자!        → 성공!

 여러 부하를 발생시키고 싶으면 replicas로 생성    n 1000: 1000개의 요청c 10: 동시에 10개의 요청\-r : 모든 응답을 무시하지 않고, 요청을 계속해서 실행\-s 60 : 응답 시간을 초 단위로 설정. 즉, 60초 동안 응답 대기http&#

control-plane-1 에서 배포를 진행하겠다.               

Kargo is designed to offer a flexible and intuitive layer atop existing GitOps tools. It enables you to define and manage the relationships between mu

기존에 운영중인 클러스터에 분산 스토리지 시스템으로 Longhorn을 사용해왔다.여러 서비스를 추가하면서 RWX PVC를 사용해야 할 경우가 많아졌는데, Longhorn이 제공하는 RWX가 성능적인 문제가 있는 것 같아서 Rook-Ceph로 전환하였다.  Rook은 쿠

출처 : https://github.com/applejag/kubectl-klock?tab=readme-ov-file대부분 kubectl을 사용하는 터미널에서 watch를 사용해 pod의 배포 상황, 삭제 상황 등을 가볍게 확인하는 경우가 많을 것이다.나의 경

kagent is a Kubernetes native framework for building AI agents. Kubernetes is the most popular orchestration platform for running workloads, and kagen