최근 Broadcom이 Bitnami를 인수하면서 Bitnami 이미지가 유료화되었습니다. 또한, Helm chart도 더 이상 유지보수가 이루어지지 않게 됩니다.
Broadcom이 Bitnami에 대한 권리를 가지게 되면서 이제 보안 설정에 대한 비용을 받겠다는 것으로 보이는데, 현재 회사에서도 Bitnami를 기존에 유용하게 사용하고 있어서 대응이 필요했습니다.
간단하지만 이를 대응하는 과정과, 후속 조치 방안을 조사하면서 들었던 여러 생각을 정리해 보았습니다.
오랜 기간 동안 진행한 Kubernetes 전환 과정 이후에도, 팀 내에서 더 나은 환경을 제공하기 위해 여러 계획을 진행하고 있습니다.
최근에는 이벤트와 트래픽에 따른 자원 관리를 본격적으로 시작할 필요성이 생겼고, 이를 위해 KEDA를 도입하게 되었습니다.
이를 구성한 과정과 느낀 점을 간단히 정리해 보았습니다.
지난 몇 개월간 Azure Kubernetes Service, Amazon EKS, 그리고 기존 서비스 전환까지 진행하며 주요 서비스를 Kubernetes 환경으로 이전했습니다.
지금도 계속 다른 작업을 진행하고 있지만, 지금까지 작업을 하면서 느꼈던 내용과 차마 이야기하지 못했던 내용들을 돌아보려고 합니다.
지난 몇 개월간 Azure Kubernetes Service와 Amazon EKS 환경을 차례로 구축하며 Kubernetes 전환의 기반을 마련하고, 일부 서비스를 실제로 전환하기도 했습니다.
최근에 본격적으로 기존 서비스들을 차례차례 Kubernetes 환경으로 이전했는데, 그 과정에서 고민한 관리 방식과 과정을 정리해 보았습니다.
인프라를 구성할 때는 항상 신중하게 계획하고 구성해야 합니다. 너무나도 당연하고 저도 계속 노력하고 있지만, 생각지도 못한 곳에서 문제가 터지기도 합니다.
지난 5월, IP 블록 충돌 문제로 인해 운영 환경 인프라를 통째로 재구성해야 했던 일이 있었습니다. 다행히도 K8s 환경을 본격적으로 이관하기 전이라 영향도가 크지 않았지만, 상당히 큰 작업이었습니다.
이번에는 이 과정에서 제가 겪은 시행착오와 그 과정에서 느낀 점을 적어보고자 합니다.
작년부터 시작한 Kubernetes 전환 작업이 조금씩 진행되고 있습니다.
이번에는 Azure Kubernetes Service에 이어 Amazon EKS 환경을 구성하며 겪었던 이슈들을 정리해 보았습니다.
현재 회사에서는 일본 리전의 VM 환경을 AKS로 전환하는 작업을 진행하고 있습니다.
추가로, 몇몇 곳에서 Azure 환경을 요구하는 경우가 더 생겼습니다.
기존 AKS 환경을 구성했던 Terraform 코드는 변수 분리 정도는 되어 있지만, 모듈화가 되어 있지는 않았습니다. 거기에 Azure 진영은 참고할 모듈도 많지 않고, 몇몇 곳에서는 특별한 조건도 있었기 때문에 모듈을 직접 작성하기로 했습니다.
이번에는 모듈을 직접 만들면서 고민했던 내용과 구현 내용을 간단히 정리해 보았습니다.
오랜만에 작성하는 블로그입니다.
업무상으로 외부에 많이 나가면서 순수하게 시간이 부족하기도 했고, 참여한 작업들의 규모가 생각보다 커서 결론이 나는 데 꽤 걸렸던 것 같네요.
다른 일들은 기회가 되면 나중에 적어 보는 것으로 하고,
최근 중요하게 진행하고 있는 작업은 사내 배포 환경을 Kubernetes로 전환하는 것입니다.
이 글을 시작으로 Kubernetes 전환 과정에서 겪은 어려움과 해결 방법들을 정리해 보려고 합니다.
프로젝트에서 고객사의 요구사항을 맞추기 위해 Istio를 사용해야 할 일이 생겼습니다.
기존에는 NGINX Ingress Controller를 사용해 왔는데, 이를 대체하기 위한 작업이 필요했습니다.
Istio를 실무에서 사용해 본 적은 처음이어서 시행착오가 많았습니다.
이 과정에서 겪었던 과정들과 문제들을 정리해 보려고 합니다.
현재 진행하고 있는 프로젝트에서 최근 부하 테스트를 담당하게 되었습니다. 테스트를 위한 도구는 여러 가지가 있지만 저희는 빠르고 간단하게 사용할 수 있는 Locust를 사용하기로 했습니다.
생각보다 Locust 사용 사례가 많지 않아서, 이 과정에서 겪었던 과정들과 문제들을 정리해 보려고 합니다.