런타임 이미지로 distroless 또는 alpine을 사용하지 않는 이유는 golang은 컴파일 시에 의존성이 전부 바이너리에 포함된채로 컴파일되기 때문에, 별도의 구성 요소없이 scratch를 사용하는 것이 더 효율적이기 때문이다.부가적인 설명을 하자면 CGO_ENABLED=0은 C 라이브러리의 연결을 완전히 비활성화하여 순수하게 GO 코드만으로 바이너리를 생성한다. GooS는 타켓 운영체제 지정. GOARCH는 서버의 아키텍처를 지정한다. 만일 설정이 없는 경우 실행되는 머신의 구성을 따라간다. -a는 의존되는 모든 패키지를 재빌드함으로써 일관성을 보장한다. -ldflags '-s -w'는 심볼 테이블 및 디버그 정보를 제거함으로써 바이너리 크기가 대폭 감소한다.UPX란 실행 파일 압축 도구로. 바..
Otel 설치설치 과정1.otel operator2. otel Collector(선택 사항으로 제외)3. Instrumentation 생성4. APP에 주석을 통한 자동 계측helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-chartshelm repo update# Otel Operatorhelm upgrade --install my-opentelemetry-operator open-telemetry/opentelemetry-operator \ --set "manager.collectorImage.repository=otel/opentelemetry-collector-k8s" \ --set admission..
상황문제에 대해 기술하자면 LitmusChaos에서는 execution plane 영역과 control plane 영역 사이에서 중간자 역할을 수행하는 subscriber가 존재한다. 실험을 실행하는 과정에서 아직 argo workflow나 실험 파드가 존재하지 않는 경우, 파드의 로그를 가져오려고 하면 일관된 로그 메시지인 “mainLogs":"Failed to get argo pod logs" 를 사용자에게 전달한다. 이러한 로그 메시지는 사용자 입장에서 직관적이지 못하다. 사용자가 구성한 설정 값이나 시스템 환경에서 에러가 발생한 것으로 착각하게 만들수 있기 때문이다. 문제 정의사용자가 파드 로그를 조회할 때, argo workflow나 실험에 대한 파드가 존재하지 않아서 발생하는 문제이다. 실험을..
컴퓨터를 강제로 껐다 켠 이후 minikube가 정상적으로 동작하지 않는다. 이러한 이유는 kubelet과 api-server가 동작하지 않고 있기 때문이다. 우선 minikube의 상태를 진단한 후 api-server 상태를 업데이트한다. api-server 상태를 업데이트했지만 kubelet과 api-server가 동작하지 않는다. 원인을 파악하기 위해 minikube에 SSH로 접속하여 kubelet 프로세스를 확인해 본 결과 실행 중이 아님을 알 수가 있었다. systemctl kubelet start를 실행시킴으로써 kubectl이 정상적으로 동작하게 되고 api-server와 통신이 이루어진다. 그러나 아직 한 가지 문제가 남아있었다. pod가 실행되었으나 deployment가 pod를 인식하..
MongoDB Authentication failedminikube에서 mongodb에 접속하고나서 명령어를 실행한 순간 인증을 요구하는 에러가 발생한다.kubectl exec -it -n litmus chaos-mongodb-0 -- mongosh --authenticationDatabase admin -u root -p 1234MongoServerError: command listDatabases requires authenticationMongoServerError: Authentication failed.use admindb.auth("root")Enter password1234****{ ok: 1 }Mongodb secondary to mastermongodb에서 master로 접근하기 위해 다..
원격 저장소의 커밋 내역을 수정하기 위해 git rebase를 수행했다. 문제는 rebase 이후 원격저장소에 커밋을 반영한 결과, rebase 이전 다른 사람들의 커밋에도 영향을 끼친것이다. 내가 작업한 커밋이 아니지만 같이 수행한 것으로 표기된다. 예상되는 원인으로는 다른 브랜치에서 작업한 후 master 브랜치에 이를 병합하고나서 rebaes를 수행한 것이 원인으로 보인다. 병합한 것은 최근이지만 커밋들은 직전의 커밋이 아닌 중간중간에 속해있기 때문이다. 로컬 저장소 git 로그 확인1.git reflog특정 시점으로 되돌아가기2.git reset --hard HEAD@{61}다른 브랜치에서 작업한 후 다시 병합을 해주었다. https://velog.io/@whoyoung90/TIL-51-git-..