나는 kubernetes 또는 AKS (Azure Kubernetes Service) 경험은 있지만, 처음 도입하려는 순간부터의 경험은 없었다 . 즉 내 솔루션을 위한 kubernetes 도입을 해본적이 없었다. 타 회사를 위한 구축만 하다보니 도입 초기부터 운영까지의
클라우드에서 리소스를 생성할 때, 정말 많은 옵션들을 볼 수 있다. Azure의 Kubernetes, AKS 또한 예외는 아니다.특정 플랫폼을 도입하기로 하였으면, 생성할 때의 옵션들을 꼼꼼히 보는것은 필수이다.생성할 때 대충대충 진행하면, 위와 같은 상황을 꽤 자주
로깅을 하자! 운영을 하다보면 엔지니어라면 피해갈 수 없는 추리물이 있다. 바로 원인분석!! 범인잡기 범인잡기?! 세상에 완벽한 솔루션은 없다. 조금 바꿔말해 보자면, 계산기 수준의 간단함이 아니라면 결함 및 오류는 언제나 일어난다고 생각한다. 아니, 계산기 수
kubernetes에서는 secret이라는 object가 있다. 이름에서도 알 수 있듯이 비밀스러운 것들을 넣고 빼는 건데 이러한 사람들이 있을 수 있다.내 yaml 파일이 어쩔 수 없이 여러 사람들과 공유되어 사용되고 있는데 이 secret 값들을 그 사람들이 보는게
우선 KEDA가 뭔지 모르는 사람들은 전에 내가 쓴 글이 있으니 참고가 필요하면 갔다오자!!https://velog.io/@pwcasdf/Azure-Kubernetes-Service-KEDA-service-bus-%EA%B8%B0%EB%B0%98-hpa-%EA
처리한 메시지가 재처리 된다.좀 더 자세히 설명해 보자면, 처리하고 나서 한참 뒤에 갑자기 동일한 시간에 메시지가 다시 처리된다.위와 같은 현상을 겪은 사람은 나와 비슷한 환경이거나, 골자는 비슷할 것이라 본다.아래는 현재 내가 사용하고 있는 환경이다.kubernete
kubernetes를 사용중 아래와 같은 피할 수 없는 딜레마에 빠질 경우가 있다.특정 툴을 container로 만들어 사용하는데 이 툴은 예를 들어 config.ini라는 파일을 통해 특정한 값들을 넣어야 한다.이러한 값들 중, 특정 id / pw를 넣어야 하는 경우
노드풀이란? Kubernetes에는 node pool이라는 개념이 있다. 이름에서 알 수 있듯 노드들의 묶음 단위로 보면 된다. 크게는 시스템에서 사용하는 system pool과 user가 사용하는 user 풀로 나눌 수 있다. user pool 또한 워크로드에 따라