All Posts

Kubernetes에서 pod가 실행될 때, 해당 process의 open file 갯수 limit이 어떻게 되는지 궁금하였다. Containerd가 systemd service로 동작하는 상황에서 systemd에서 LimitNOFILE이 inifinity로 설정되어 있는 것을 확인하였다. infinity가 Ubuntu systemd 240 버전 이상에서는 process에 최대로 할당할 수 있는 File 갯수인 fs.nr_open 값으로 설정된다. 실제로 test용 pod를 띄어서 containerd에 의해서 실행되는 process의 nofile limit이 LimitNOFILE에 설정된 값으로 동일하게 설정되는 것을 확인하였다.

Kubernetes에서 Tekton Chain을 통해서 어떻게 Software Supply Chain Security를 구성할 수 있는지 확인했다. Tekton Pipeline으로 git clone을 하고, container image를 build하고, 최종적으로 OCI registry에 push하도록 구성했다. 그리고 Tekton Chain이 어떻게 in-toto spec의 Attestation 정보를 남기는지 확인하였다.

네이버 클라우드 쿠버네티스 서비스에서 HostPort를 설정하였는데, 정상적으로 Node Port를 통해서 Container에 접근할 수가 없었다. 처음에는 CNI plugin portmap을 설정하여 HostPort를 Iptables Rule로 적용하도록 하였다. 하지만 현재 운영하는 Kernel 버전이 kube proxy를 대체할 수 있는 것을 파악하였고, default로 설정된 KubeProxyReplacement=disabled을 KubeProxyReplacement=strict으로 설정하여 Cilium eBPF로 대체하여 사용하였다.

Cert Manager의 DNS provider 목록에 Naver Cloud DNS는 없었다. 하지만 Cert Manager에서 새로운 DNS provider를 직접 연결해서 사용할 수 있도록 webhook solver라는 것을 제공한다. 따라서 Naver Cloud API를 사용하여 webhook 코드를 작성하고, Github Action을 통해서 Image와 Helm chart를 배포해서 사용했다. Cert Manager에서 Boilerplate code와 test framework를 제공하여 비교적 쉽게 작성해서 사용할 수 있었다.

내가 좋아하는 저자 Adam Grant의 새 책이 나와서 읽게 되었다. 성장 마인드셋을 믿지만, 성장이 정체되고 있다라는 불안감에 있는 나에게 큰 용기를 주는 책이었다. 다시 한번 나의 목표에 도달하기 위해서 내가 할 수 있는 시도들을 생각해보고, 조금씩이라도 어제보다 더 나아지는 오늘에 집중하자고 다짐했다. 지금까지 나의 성장들이 가파르게 우상향 한 것은 아니였다. 때로는 역석장 하는 것 같아서 불안하고 좌절했다. 하지만 전체 과정에서 컴포트 존을 나와 계속 도전을 해온 점과 성장하기 위해서 포기하지 않고 계속 노력해 온 점에 대해서 스스로 칭찬해주었다. 그리고 이 책을 통해서 아들의 성장과정에서 어떠한 것을 중요하게 생각하고 가르쳐줘야할지 고민해볼 수 있었다. 주도적으로 계속해서 배울 수 있는 힘을 배우고, 그 과정에서 재미도 느낄 수 있었으면 좋겠다

GPTCache를 사용하여 LLM에 질의를 할 때, 의미적으로 유사한 질문에 대해서는 Cache에 저장된 답변 값을 사용할 수 있도록 구성해보았다. Langchain과 Langserve를 통해서 간단히 Cache를 제공하는 API server를 만들 수 있었다. Default로 설정된 GPTCache에서 의미적으로 충분히 다른 질의에 대해서도 기존 Cache값을 사용하는 False Positive 결과를 받았다. 그래서 Default로 사용된 Similarity Evaluation 방법이 어떻게 동작되는지 살펴보았다. 이해를 바탕으로 Threshold값을 변경하여 발생했던 False Positive case를 제거해보았다. 앞으로 Cache hit rate, Accuracy, Speed를 고려하여 서비스에 적합한 Evaluation 방법을 선택하기 위해서는 Default 말고 다른 옵션들도 확인할 필요가 있겠다.

OpenTelemetry collector를 사용하여 tracing과 logging을 같이 하는 것을 검토하였다. Kubernetes와 멀어져 있던 사이에 OpenTelemetry 커뮤니티가 엄청나게 성장한 것을 깨닫게 되었다. Log에 traceID를 남기고 그걸로 Tracing 정보를 볼 수 있도록 구성했고, Grafana 하나에서 통합적으로 볼 수 있도록 Loki와 Tempo를 Exporter로 사용했다. 아직 Python과 Nodejs에서는 Log쪽의 상태는 Development나 Experimental이기 때문에, receiver에서 filelog를 사용하여 Kubernetes log file을 fluentbit처럼 tail해서 가져오고 traceId를 log에 넣어주는 instrument libary를 사용했다.

Vault의 secret engine을 사용하여 네이버 클라우드의 임시 인증키를 발행하고 싶었다. 네이버클라우드는 AWS, Azure처럼 builtin plugin으로 제공하지 않는다. 하지만 custom secret engine을 vault framework SDK를 통해서 쉽게 만들 수 있다. 네이버 클라우드에서 STS API를 제공하기 때문에, custom secret engine을 통해서 임시 인증키를 발행하는 것을 테스트 해보게 되었다. 처음에 구조를 이해하는데 좀 시간이 걸렸지만, Vault Tutorial에서 친절하게 설명하고 있어서 비교적 쉽게 만들 수 있었다.

GitOps에서 Secret을 어떻게 관리할지 고민을 하였고, 개발자들의 인지부하를 줄이기 위해서 Vault UI로 자신의 앱의 비밀값을 관리하는 것이 제일 효율적이라는 판단을 했다. Vault secrets operator가 GA로 공유가 되었고, Secrets Store CSI나 External secrets 프로젝트보다 깔끔한 방식이라는 생각이 들었다. Vault secrets operator의 CRD로 vault secret과 kubernetes secret의 sync를 맞추고, reloader로 secret이 변경되었을 때 다시 pod를 배포하는 것을 테스트해보았다.

AWS Cloudformation에서 Secret Manager의 값을 참조하도록 할 수 있다. AWS SAM을 사용하여 배포된 Lambda의 환경변수가 Secret Manager의 값을 참조하는 경우가 있었다. 그런데 Secret manager의 값을 변경하여 다시 배포하여도 변경된 값이 Lambda 환경변수에 반영이 되지 않았다.🧐 AWS SAM의 리포에 관련된 Issue가 있었고, 제안한 해결방법을 적용하였다. 살짝 삽질을 했기 때문에 기록을 남겨 본다.🤪