CKA, CKS 까지만 취득하고, 쿠버네티스 자격증은 충분하다고 생각했는데 이번에 kubestronaut 라는 것을 접하게 되었습니다. kubeastronaut 는 5개의 쿠버네티스 자격증 CKAD, CKA, CKS, KCNA, KCSA 를 모두 취득하면, 리눅스 파운데이션에서 주어지는 칭호?입니다. 그래서 어차피 CKS 도 취득했겠다, 나머지도 취득해야겠다고 마음 먹었습니다.  그렇게 마음 먹고 그 마음 먹은 주에 바로 KCNA 를 취득하였습니다. 그럼 바로 팁을 공유해보죠! Tips 첫번째 가장 먼저 역시 시험이 어떤 커리큘럼으로 진행되는지 확인해봐야겠죠? 뭔가 엄청 많은거 같은데, CNCF 프로젝트와 쿠버네티스를 조금이라도 다뤄보셨다면 사실 공부하지 않아도 어렵지 않게 취득할 수 있을거라 생각합니다..

비록 크지 않은 규모의 쿠버네티스지만 2년 동안 운영하면서 많은 것들을 경험할 수 있었습니다. 경험속에서 배울 수 있었던 작은 팁들을 공유하고자 합니다. 제가 공유하고픈 팁들은노드 및 파드 스케줄링HA 유지쿠버네티스 매니페스트 관리IaC입니다. 그럼 바로 본론으로 가보죠. 렛츠두더코드~   노드 및 파드 스케줄링 쿠버네티스를 처음 공부했을 때, 노드 및 파드 스케줄링 파트는 그렇게 유심히 보지 않았습니다. 그렇게 어려워 보이지 않았거든요. 그냥 Resource Request/Limit, NodeAffinity/PodAffinity/AntiAffinity 등 yaml 에 작성하면 파드는 그에 맞게 알아서 배포가 되니깐요. 당연한 것이 공부할땐 기껏해야 3개 정도의 파드로 진행하는데, 현실에선 최소 몇 백개..

현재 글은 상편에서 이어집니다.들어가기 앞서 해당 글에서는 C Compiler 에 대한 지식을 필요로 합니다. 하지만 전 C Compiler 에 대해 자세히 알지 못하기 때문에 틀린 부분이 있을 수 있으며, 언제든지 지적바랍니다. 그리고 Github Action 과 관련된 개념 부분은 따로 설명하지 않습니다.  시나리오는 크게 Local 영역과 Remote(Git Runner) 영역으로 나눌 수 있습니다.  Local Local 영역부터 시작해보죠. Local 영역에선 미리 Python 을 빌드 한 후에 Artifacts Repository 에 업로드 합니다.Official Setup Python 액션을 보면 versions-manifest.json 에 Python 을 다운받을 수 있는 URL 이 명시되..

들어가기 앞서 해당 글에서는 C Compiler 에 대한 지식을 필요로 합니다. 하지만 전 C Compiler 에 대해 자세하게 알지 못하기 때문에 틀린 부분이 있을 수 있습니다. 지적은 언제든지 환영합니다 :) Github Action Marketplace 에는 다양한 액션들이 존재합니다. 그 중 Setup Node, Setup Go, Setup Python 액션 등을 통해서 필요한 언어나 툴을 러너에 설치하게 됩니다. 만약 러너에서 파이썬이 필요하다면,  Setup Python 액션을 실행해서 파이썬을 사용할 수 있는 환경을 구성할 수 있습니다.  그런데,  아쉽게도 Setup Python 액션은 Linux x64, Windows x64, MacOS Apple Silicon(Intel 포함) 은 지원..

k6 는 Grafana 사에서 제공되는 퍼포먼스 테스트 툴입니다. k6 를 이용하면 마치 여러 명의 유저가 있는 것처럼 애플리케이션 퍼포먼스 테스트를 진행할 수 있습니다. Smoke Test, Load Test, Stress Test 등 다양한 테스트를 쉽게 진행할 수 있도록 도와줍니다. 그리고 자바스크립트로 제공되기 때문에 어렵지 않게 테스트 시나리오를 작성할 수도 있죠. 아래는 아주 간단한 k6 스크립트입니다.import http from 'k6/http';import { sleep } from 'k6';export const options = { vus: 10, duration: "10s",}export default function() { http.get('http://test.k..

테라폼은 대표적인 IaC 도구로 AWS 와 같은 클라우드 환경을 코드로 구성할 수 있다는 장점이 있습니다. 그리고 보통 클라우드 환경은 Dev 과 Prod 으로 나뉘게 됩니다.  한편, 테라폼을 이용해서 리소스를 생성하게 되면 backend 라는 곳에 tfstate 를 저장하게 됩니다.tfstate 는 리소스의 구성 정보를 가지고 있는 파일이고, backend 는 이러한 tfstate 를 저장하는 보관소 입니다. backend 는 로컬이 될 수도 있고, AWS S3 와 같은 오브젝트 스토리지도 될 수 있습니다. 한번, AWS S3 에 Demo 버킷을 Dev 환경과 Prod 환경에 같은 코드를 가지고 동일하게 생성한다고 가정해보겠습니다. 예제 코드는 여기서 가져왔습니다! 사용..

이전 글인 [트러블 빵야] 6개월 동안 즐거웠다.. 잘가고 다신 보지 말자! - 504 Gateway Timeout (이슈 편) 에서 이어집니다! 곰곰이 생각해봤습니다. 504 Gateway Timeout ... 결국 어디선가 Response 를 받아야 하는데 받지 못해서 생기는 이슈 입니다. 어디서 Response 을 받지 못했을까요? 위 아키텍처만 봤을땐, 더 이상 도저히 모르겠습니다.  그래서 위 이미지보다 조금 더 아키텍처를 구체화시켜봤습니다. AWS ALB 는 Target Group 에 등록된 노드에게 트래픽을 라우팅 해주는데, Karpenter 로 생성되는 노드들은 모두 동일한 Target Group 에 등록됩니다. (대수롭지 않게 동일한 Target Group 에 등록되게끔 구성했죠) 여기서..

개발을 하는데 있어 컨테이너는 더 이상 빠질 수 없을 만큼 중요한 개념이 되었습니다. 그리고 Docker 는 컨테이너 매니지 툴 중 가장 대표적이라고 볼 수 있죠. 컨테이너를 실행하기 위해선 이미지가 필요하고 보편적으로 Docker 를 통해 이미지를 만들게 됩니다. Dockerfile 에 작성 한 후 Docker 커맨드를 이용하면 이미지가 만들어지고 아주 쉽게 컨테이너를 실행할 수 있습니다. 이미지를 빌드 하는 데 있어서 물론 경량화도 중요하지만, 그 못지 않게 이미지 보안도 중요합니다. --previliged 권한을 부여하는 걸 지양하고, Dockerfile 에 직접적으로 crendentials 관련한 정보를 추가(COPY) 하는 걸 주의해야 합니다. trivy 를 이용하면 손쉽게 이미지의 취약점 검사..

쿠버네티스 클러스터에는 3가지의 AutoScaler 가 있습니다. HPA, VPA, CA 죠. 간단히 설명해보자면,HPA : Horizontal Pod Autoscaler 의 줄임말로, 파드의 갯수를 확장/축소 해줌VPA : Vertical Pod Autoscaler 의 줄임말로, 파드의 갯수가 아닌 지정된 리소스를 확장/축소 해줌CA : Cluster Autoscaler 의 줄임말로, 노드의 갯수를 확장/축소 해줌 HPA, VPA 는 Metrics Server 가 설치되어 있어야 하며, 또 VPC 같은 경우는 따로 설치해주어야 합니다. 그리고 CA 는 보통 Karpenter 를 사용합니다. 이번 글에서는 HPA 에 대해 다뤄보고자 하는데, 사실 HPA 는 어려운 개념이 크게 없다고 생각합니다. 따라서 ..

테라폼을 처음 시작하면 헷갈리는 명령어 옵션이 있습니다. 바로 terraform init 명령어의 -migrate-state 와 -reconfigure 죠. 보통 backend 구성을 변경하면 해당 옵션을 사용하라는 명령어를 볼 수 있습니다. 로그에서 -migrate-state 와 -reconfigure 에 대한 설명이 나와있지만 딱히 와닿지는 않습니다. tfstate 의 방향성을 좌지우지 하는 옵션이기 때문에 잘못 썼다간 인프라가 꼬일 수도 있습니다. 예를 들어, 분명 변경(0 to change)하는 건데 새롭게(1 to add) 생성한다는 문구를 볼 수 있죠. 이런 경우는 보통 backend 구성을 변경하고, -reconfigure 를 사용했을 때 발생합니다. 예제여서 딱 하나의 state 만 존재하..

쿠버네티스 내부끼리 통신을 할 때 보통 서비스의 도메인 svc.cluster.local 을 이용하여 통신하게 됩니다. 외부에서 내부로 들어오는 통신에 대해서는 Ingress 를 이용해 https 통신을 하게되죠. 하지만 Ingress 는 내부 통신에 대해서는 https 통신을 보장해주진 않죠. 이 부분에 대해서는 Istio 의 mTLS 를 이용해서 파드와의 통신은 모두 https 통신을 하게 할 수 있습니다. Istio 의 mTLS 가 궁금하다면? [Istio] 쉿! 우리만의 비밀이야 - mTLS (확인편) [Istio] 쉿! 우리만의 비밀이야 - mTLS (검증편) 그렇다면 mTLS 를 이용하지 않고 내부 통신은 어떻게 https 통신을 할 수 있을까요? 정답은 간단합니다. 파드 마다 certifica..

EKS 와 같은 클라우드가 제공해주는 쿠버네티스가 아닌, 온프레미스 환경에서 쿠버네티스를 설치한다고 하면 보통 kubeadm 이라는 툴을 이용해서 구성하게 됩니다. Control Plane 은 kubeadm init 를 통해 구성되고, Data Plane 은 kubeadm join 을 통해 쿠버네티스에 조인하게 됩니다. kubeadm 툴 하나면 API Server, Scheduler, Control Manager, ETCD 등 Control Plane 에 필요한 모든 것들이 마법처럼 자동으로 구성되죠. 물론 kubelet 그리고 containerd 와 같은 cri-구현체는 이미 실행되고 있어야 합니다! 자동이란 것이 확실히 편의성을 제공해주긴 하지만, 자동으로 구성되기 때문에 그 안에서 무슨 일이 일어..

예전부터 쿠버네티스를 관리하는 데 있어서 궁금한 점이 있었습니다. "엄청 나게 많은 로그를 생성하는 애플리케이션들로 인해 노드의 디스크가 부족해지면 어떡하지?" "계속 새로운 컨테이너 이미지를 다운 받아서 그로 인해 노드의 디스크가 부족해지면 어떡하지?" 노드의 디스크가 부족하게 되면 노드에서 DiskPressure 라는 메시지를 뱉게 될 것입니다. 그런데 궁금한 요점은 디스크가 부족할 때 "어떻게 해결하냐" 가 아니고 "어떻게 예방하냐" 입니다. 그래서 이번 글에서는 예방하는 방법에 대해 알아보고자 합니다. 렛츠두더코드~ 저는 개인적으로 쿠버네티스를 관리하면서 가장 중요시하게 생각하는 키워드가 있습니다. 바로 일시적(empheral) 과 동적(Dynamic) 입니다. 예를 들어, 쿠버네티스의 가장 기본..

앞서 작성했던 트러블 슈팅 관련 글 중에 한 글은 제목이 "타노스는 이런 느낌일까?" 라고 지었을 만큼 꽤나 힘들었던 에러였죠. 근데 이번에 겪은 이슈는 앞선 글 제목에 타노스 라고 붙이기 민망할 정도로 원인을 찾기가 힘들었고, 또한 이슈가 6개월이나 지속될 정도로 마음 아팠던 트러블 슈팅이였습니다.  들어가기 앞서 간략하게 환경은 다음과 같아요. 쿠버네티스는 AWS EKS(v1.28) 를 이용하고 있으며, 서비스메시 서비스인 이스티오(v1.18)의 인그레스 게이트웨이와 AWS ALB 를 맵핑하여 클러스터 외부에서 클러스터 내부 서비스에 접근이 가능합니다. 그리고 여기서 사용할 내부 서비스는 ArgoCD(v2.5) 입니다. 이슈는 ME! 가 ArgoCD 에 접근을 했을때 불특정하게 504 Gateway ..

쿠버네티스 환경에선 ARC 를 이용하면 어렵지 않게 다양한 OS 위에 오토스케일링에 기반한 Runner 구현이 가능합니다. Karpenter 와 함께라면 더 효율적이죠. (Karpenter 과 궁금하다면 여기 참고, ARC 가 궁금하다면 여기 참고) 또한 EKS 에서 Linux 와 Windows 기반의 노드를 지원해주기 때문에 띄우기만 한다면 파드 단위로 Runner 를 배포할 수 있습니다. (EKS 에서 Windows 를 활성화 하는 방법이 궁금하다면 여기 참고) 하지만 MacOS 는 얘기가 달라요.. EKS 에서 지원을 안해줍니다.. 그래서 만약 MacOS 기반의 워커 노드를 프로비저닝 하려고 한다면, 아마 MacOS 기반의 인스턴스를 띄운 후 거기서 수동으로 EKS 클러스터에 조인해야 할 것입니다...