정말 오랜만에 블로그 글을 작성하게 되었다. 올해는 회사 일이 정말 바빴기 때문이였다.. 사실 지금도 여유롭진 않은데 그래도 뭐라도 작성해야겠다 싶어서 몇자 적어보려고 한다! 이번에는 GKE 에서 Ingress API 기반으로 생성한 L7 LB 에 Wildcard Google Managed Certification 을 사용할 수 있는지에 대해 알아보려고 한다. 바로 본론으로 들어가보자! GKE Ingress API 문서를 살펴보면 HTTP(S) LB 에는 Wildcard Google Manged SSL Cert 는 사용할 수 없다고 한다.그런데 결론부터 말하면 가능하다! 저 문장이 굉장히 애매모호하다. 아마 대부분의 사람들은 저 문장을 봤을때 단순히 L7 LB 에 와일드카드 도메인 인증서를 사용하지 못할..

새해가 되면 그 해의 목표를 매번 세우는데 올해 두번째 목표가 CNCF Ambassador 가 되는 것이였다. CNCF Ambassador 로 가는 길은 생각보다 쉽지 않은데 아래 기준 중 2개 이상을 만족시켜야 한다. 어찌됐든 CNCF Ambassador 가 되기 위한 첫번째 과제 중 하나가 CNCF Project 에 Contribution 을 해서 DevStat 이라는 걸 20개 이상 얻는 것이였다. 어떤 기준으로 주는 지는 정확히 모르겠지만 확실한건 CNCF Project 에 Contribute 하면 얻을 수 있다! 글을 쓰는 시점 기준으로 38개가 되면서 CNCF Ambassador 기준 중 하나는 만족시켰다. 하지만 이번 글은 CNCF Ambassador 에 대한 글이 아니고 CNCF Proj..

Google Cloud Next 25를 다녀오며 (1) 를 먼저 봐주세요! Day 3Google Cloud Next 25 의 둘째 날이 열렸다!과학인 K5 를 타고, Google Cloud Next 25 가 열리는 만달레이 베이 컨벤션으로 향했다. 가는 길에 라스베가스 랜드마크 중 하나인 룩소 호텔도 봤다. 오래되서 그런지 전체적으로 노후됐다. 기분 탓인지 첫째날 보다 덜 붐비는 느낌이였다. 다들 뭔가 바쁘다.. 왜 바쁠까?? 왜 우리는 여유롭지...??왜냐 우린 오늘 세션이 2개밖에 없기 때문이지!! 첫째 날에 둘러볼 건 다 둘러봐서 딴데로 새지않고 곧장 세션이 열리는 곳으로 향했다. 첫번째 발표하셨던 구글러 분은 불곰국 사람이였는데, 굉장히 무섭다... 발음도 불곰국 성향이 강해서 알아듣긴 힘들었다...

회사에서 힘을 보태주신 덕에 라스베가스에서 열린 Google Cloud Next 25 에 다녀오게 되었습니다. 4월 09일 - 4월 11일까지 총 3일 거쳐 진행되었습니다. 다시 한번 Google Cloud Next 25 에 보내주신 CTO님과 팀 리더님에게 감사합니다 :) 그럼 Google Cloud Next 25 그 현장 속으로 레츠고~ Day 14월 08일 오후 09시 라스베가스행 비행기에 탑승하기 위해 같이 가게 될 팀원 분과 인천공항 제2 여객 터미널로 향했다. 체크인하고 탑승까지 1시간정도 남아서 뭐하며 시간을 보낼까 고민하다 팀원분이랑 커피 내기를 하게 되었다.언제나 그렇듯 내기에서 이겨 탑승구 근처에 있는 투썸에서 커피를 공짜로 먹을 수 있었다. 너무 달아서 아이스티를 잘못 주셨나 했다!..

이스티오는 디버깅이 어려운 툴 중 하나라고 생각합니다. 그 이유는 간단하죠. 이스티오 자체가 어렵기 때문입니다. 서비스 메시 툴 답게 많은 네트워크 지식을 요구하기 때문에 디버깅이 어려울 수 밖에 없습니다. 네트워크 관련된 부분이 많기 때문에 어디서부터 디버깅을 해야 하는지 감도 사실 잘 안 옵니다. 이게 이스티오 문제인가? 클라우드 문제인가? 쿠버네티스 문제인가? 판단하기까지도 오래 걸리죠. 그러다 보니 애플리케이션을 배포하던 중 약간이라도 이스티오와 관련한 문제가 발생했다고 생각하는 경우 그냥 애플리케이션에서 이스티오를 빼버립니다. 정확히는 이스티오 사이드카(프록시)를 레이블을 통해 인젝션에서 제외시켜 버리는 것이죠.  이스티오 사이드카를 주입하지 않았기 때문에 대부분의 문제는 해결되지만, 이는 근본..

AWS 에서 GCP 로 넘어가면서 자연스레 AWS Secrets Manager 에서 GCP Secret Manager 로 넘어가게 되었습니다.서비스 이름이 AWS 에선 Secrets 복수를 사용하고, GCP 에선 Secret 단수를 사용하는데 글 후반부에서는 왜 이렇게 지었는지 대략적으로 알 수 있게 됩니다! Secret Manager 라는 서비스는 사실 특별한 기능은 없습니다. 그저 시크릿을 저장하는 저장소 역할을 하는데, 쿠버네티스 환경에서 External Secrets 나 Argo Vault Plugin 을 사용하면 원하는 시크릿을 쉽게 가져올 수 있다는 장점이 있습니다. AWS Secrets Manager 에 익숙한 상태였기 때문에 GCP 에서도 비슷하게 가져가면 될 것 같다라는 생각으로 마이그레..

해당 글은 이스티오 인 액션이라는 책의 일부 파트를 참고하였고, 책에서 다뤘던 방법보다 한 단계 더 나아가서 진행했던 내용을 바탕으로 작성하였습니다.이스티오 인 액션은 이스티오에 관한 책인데, 최근에 읽었던 중에 책 중에 가장 흥미롭게 읽은 책이였습니다.이스티오가 궁금하다면 많은 도움을 얻을 수 있는 책으로 적극 추천합니다! 다시 본론으로 돌아와서 ksniff 는 tcpdump 를 사용해 파드의 네트워크 트래픽을 포착하고 이를 와이어샤크로 리다이렉트하는 kubectl 플러그인입니다. ksniff 를 설치하기 위해선 우선 krew 를 먼저 설치해주어야 합니다. krew 문서로 가서 그대로 진행해줍니다. 저 같은 경우는 아래 쉘 스크립트를 실행시켰습니다.$ ( set -x; cd "$(mktemp -d)"..

해당 글은 틀린 부분이 있을 수 있습니다. 마음껏 지적해주세요! 쿠버네티스 위에 있는 모든 파드와 노드는 ephermeral 하게 디자인 되었습니다. 그에 따라 파드와 노드는 언제 갑자기 급사? 할지 모릅니다. 하지만 급사 한다고 해서 서비스에 영향이 가선 안됩니다. 그렇기 때문에 쿠버네티스를 구성할 때 고가용성(HA) 은 반드시 동반되어야 합니다. 고가용성을 유지하지 위해서는 여러 절차가 동반되어야 하는데, 이번 글에서는 그 중 Stateful 한 서비스의 고가용성을 유지하는 방법 중 하나인 '리더 선출 메커니즘(Leader Election Mechanism)' 에 대해 알아보려고 합니다. 그 전에 Stateless 한 서비스의 고가용성부터 알아봅시다. Stateless 한 파드가 여러 개 있고, Se..

거의 두달이 넘도록 블로그 글을 작성하지 못했는데, 강의를 준비하느냐 그랬습니다!! 3개월 정도 준비를 했는데, 이제야 런칭을 하게되었습니다. 크지 않은 규모에서 쿠버네티스를 사용하면서 필요한 툴들이나 고가용성을 유지하기 위한 팁들을 다루는 강의입니다.쿠버네티스 기본 개념 강의는 아닙니다!   쿠버네티스 생태계는 CNCF 를 필두로 엄청나게 방대합니다. 그에 따라 어떤걸 사용할지도 쿠버네티스를 사용하면서 큰 고민거리입니다.또 IaC 를 이용해서 인프라를 코드로 관리하고 싶을텐데, 이러한 고민거리를 해결하는데 있어서 조금이라도 도움이 되었으면 하는 바람에 강의를 준비하게 되었습니다. 짧은 시간 내에 최대한 많은 걸 담아냈어야 했기 때문에 다소 부족한 부분이 있으나, "이런식으로 쿠버네티스가 돌아가는 구나"..

예전에 아래와 같은 글을 작성하였는데, 이후 크게 만지지 않아서 이번에 BIOS 모드 켜서 Proxmox 를 싹 밀어버렸고, 새롭게 다시 출발하자는 의미에서 Proxmox 재설치와 이번에는 Kubespray 를 이용해서 쿠버네티스를 설치했습니다. Proxmox 는 예전과 같은 방법과 똑같이 부품별로 구매해서 조립한 미니PC 에서 설치했습니다.저의 미니PC 가 궁금하다면 여기 클릭! 제 미니 PC 의 사양은 CPU 16, RAM 64GB, SSD 1TB 입니다. 그리고 총 4대의 Ubuntu Jammy 를 준비했고, 한대는 마스터로 나머지는 워커 노드로 사용했습니다.k8s-worker-03 도 4CPU 를 주고싶었지만.. 추후 다른곳에서 혹시 모를 CPU 를 사용할 수 있으니 2CPU 만 주었습니다.CPU..

틀린 부분이 있을 수 있습니다. 만약 있다면 지적해주세요 :)  쿠버네티스에서 ReplicaSet 을 통해 3개의 파드를 배포했다고 생각해봅시다. 이때 하나의 파드를 삭제하게 되면 곧 다시 파드가 생성됩니다. 즉, 파드가 최소 3개 이상이 실행되도록 ReplicaSet 를 배포했기 때문에 죽었던 파드를 새롭게 소생시킵니다. 이는 쿠버네티스의 특징 중 하나인 Self Healing 이기도 합니다.ReplicaSet, Deployment 등에서 명시하는 Replica 의 갯수는 고정/최대가 아닌 최소를 의미합니다.3개라고 가정했을 때, 롤링업데이트나 비자발적인 종료에 의해 3개 이상의 파드가 존재할 수 있기 때문이죠. 그럼 이걸 좀 더 전문적?으로 접근해봅시다. 우리가 원했던(Desired) ReplicaS..

이번 글의 주제인 "IRSA" 는 이해하기도 힘들었지만, 이걸 글로 작성하는 건 더 어려워서 많은 블로그 글들과 강의를 참고했습니다.틀린 부분이 있을 수 있으며, 아래에 명시한 참고 블로그들도 읽어주세요!  IRSA 는 IAM Roles for Service Account 의 약자로, Kubernetes 에서 AWS 리소스에 안전하게 접근할 수 있도록 하기 위한 메커니즘입니다. IRSA 를 사용하면 쿠버네티스 클러스터 내의 특정 Service Account 에 AWS IAM Role 을 매핑할 수 있습니다. 이를 통해 해당 Service Account 이 AWS 리소스에 접근할 수 있는 권한을 얻습니다.  IRSA 는 AWS 에서 제공하는 OIDC 와 IAM Role 을 사용하여 쿠버네티스 파드가 AWS..

드디어 kubestronaut 를 취득하였습니다!  계획대로 잘 풀려서 다행입니다. kubestronaut 은 CNCF 에서 임명하는 쿠버네티스 리더?로 CKA, CKAD, CKS, KCNA, KCSA 를 모두 취득하면 부여됩니다. CKA, CKAD, CKS, KCNA, KCSA 는 각 2년의 유효기간이 존재하지만 kubestronaut 은 유효기간이 없기 때문에 따놓으면 어찌됐든 좋다고 생각해서 CKS 가 만료되기 전에 빨리 따버렸습니다. kubestronaut 유효기간이 존재한다고 하네요 ㅜㅜ   심지어 kubestronaut 은 글 작성 기준으로 현재 저 포함 한국에 11명, 전 세계에 424명 밖에 되지 않습니다.  그리고 kubestronaut 되면 CNCF 홈페이지에 얼굴이 기재됩니다! (뿌듯..

CKAD 까지 취득하면서 kubestronaut 의 요구 조건을 충족시켰습니다! 일주일 내로 따로 메일을 준다고 하니 기다려야 하겠네요. 그럼 kubestronaut 후기는 다음 글에서 다루고, 이번 글에서 바로 CKAD 팁을 공유해보죠!  Tips 첫번째가장 먼저 역시 시험이 어떤 커리큘럼으로 진행되는지 확인해봐야겠죠? 뭐가 많긴 하지만, 어려운 파트는 없습니다. 쿠버네티스의 아주 기본적인 것들만 다루고 있습니다. 만약 실무에서 쿠버네티스를 써본 경험이 있다면, 무리없이 충분히 커버가 가능하다고 생각합니다. 두번째KCSA 와 KCNA 가 총 90분으로 진행되는 객관식 시험(Mutliple Exam) 이였다면, CKAD, CKA, CKS 는 총 2시간으로 진행되는 핸즈온 시험입니다. 따라서 상황이 주어진..

KCSA 시험은 꽤나 걱정스러웠는데 다행히 취득하면서 kubestronaut 까지 CKAD 만 남았습니다! 거의 다 왔습니다. 그럼 거두절미 하고 바로 팁으로 넘어가보죠!  Tips 첫번째 가장 먼저 역시 시험이 어떤 커리큘럼으로 진행되는지 확인해봐야겠죠? 아무래도 KCNA 와 달리 보안 관련한 항목들이 많습니다. KCNA 와 KCSA 는 CKA, CKS 보기 전 필기시험? 느낌인데, 저는 이미 CKS 를 취득했기 때문에 주제들이 엄청 이질적이진 않았습니다. 아! KCNA, KCSA 는 CKAD, CKA, CKS 와 달리 핸즈온 시험이 아닌 객관식(Multiple Choice Exam) 입니다! 그리고 60문제 총 90분으로 진행됩니다. 확실히 KCNA, CKA 얘네는 20분도 안걸렸는데, CKS 는 시..