Spring boot 웹 서버를 개발하고 Kubernetes에 배포할 때, Profile(local, dev, prd, ...)을 설정하는 법을 알아보자. Dockerfile을 사용해 컨테이너 이미지 빌드 Dockerfile을 통해 이미지 빌드 시, ENTRYPOINT에서 Jar 파일을 실행하며 Dspring.profiles.active 옵션을 통해 설정할 수 있다. ... ENTRYPOINT ["java", "-Dspring.profiles.active=dev", "-jar", "some.jar"] 해당 컨테이너 이미지를 실행시키면, dev profile로 설정되어 Spring boot 웹 서버가 실행된다. Buildpacks(ex. gradle bootBuildImage)를 통해 컨테이너 이미지 빌드..
Kubernetes를 CLI 상에서 활용하다보면 특정 리소스의 uid를 출력할 일이 생긴다. 그럴 때 마다 `kubectl edit`을 통해 uid 값을 확인하거나, `kubectl get kind/resource -o yaml`로 확인하곤 했다. 근데 이게 한 두 번이면 상관이 없는데, Operator를 개발하며 계속적으로 확인해야 했고 이 귀찮음을 이겨내고자 리눅스 커맨드라인을 사용하기로 했다. 그래서 결국 아래와 같이 하면 uid를 뽑아낼 수 있다. kubectl get pod request-pod -o yaml | grep uid | cut -d ":" -f 2 cut 대신 awk를 통해서도 뽑아낼 수 있다. kubectl get pod request-pod -o yaml | grep uid | ..
Operator에서 Controller를 만들 때, 해당 리소스의 status, spec 을 명시해주어야만 한다. spec 은 말 그대로 해당 리소스의 스펙을 의미해서 별로 헷갈리는게 없었는데, status 는 뭐지 하는 생각과 동시에 spec 도 해당 리소스의 스펙이라지만 어떻게 되는거지 라는 생각이 겹쳐져 전체가 헷갈리게 되버렸다. TL;DR spec: 원하는 상태(desired state)를 의미 status: 현재 상태(current state)를 의미 spec, status 가 다르다면, 쿠버네티스 시스템/Operator 등을 통해 status를 spec에 맞게 변경해나가게 된다. 단순히 보면 spec과 status가 같은 값을 가지고 status를 spec으로 맞춰주겠구나 할 수 있지만, 꼭 ..
Kubernetes Events는 하나의 Kubernetes 리소스 타입으로서 Kubernetes 리소스들의 state 변화, 에러 또는 시스템에 특정 메세지를 전파해야할 때 자동으로 만들어집니다. 이러한 Kubernetes Events 리소스는 Kubernetes 개발 및 운영하며 디버깅시에 매우 유용하게 사용됩니다 (공식문서에서도 디버깅 시에 Event를 활용하고 있습니다). Events 조회 Kubernetes Event는 어떻게 조회할 수 있을까요? 사실 Kubernetes를 다뤄보았다면 한번 쯤은 Events 리소스를 본 적이 있을겁니다. 가장 흔한 예로 이미지 Pull 실패 가 있겠네요. 잘못된 컨테이너 이미지를 입력해서 Deployment 또는 Pod를 생성해서 조회하면 아래와 같은 오류가 ..
helm 차트 생성 helm create template, test, values.yaml, Chart.yaml, README.md 등 파일들이 chart-name 디렉토리에 생성된다. helm 차트에 대한 조회 helm show 해당 차트에 대한 리소스를 조회할 수 있다. 근데, 사실 직접 파일 찾아서 cat으로 조회하는 것과 큰 차이가 없어서 별로 사용하지 않는다고 한다. cat 과의 차이라면 cat은 주석을 포함해 보여주지만, show를 사용하면 주석은 포함되지 않고 보여준다고 함. helm template에 values 넣어서 출력해보기 helm template helm chart 설치 전에 values가 들어간 상태로 결과를 출력해보고 싶을 때 사용한다. 설치 전, values가 제대로 들어가는..
Helm 설치 # mac: helm 키워드 자동완성 기능 source "${fpath[1]}/_helm" # helm version 확인 helm version # kubernetes config 확인 >> kubectl 사용 cd ~/.kube/ helm repository 설치 Artifact Hub Find, install and publish Kubernetes packages artifacthub.io # repo 등록 helm repo add # helm repo add bitnami https://charts.bitnami.com/bitnami # repo 조회 helm repo list # chart 찾기 helm search repo # repo에 등록된 모든 chart 출력 helm s..
쿠버네티스에서 파드를 만들었다하자. 해당 파드에서는 특정 컨테이너가 stdout을 통해 logging을 한다. 그럼 보통 해당 파드의 로그를 확인하고 싶을 때, 아래의 명령어를 사용한다. kubectl logs 좀 더 상세히 보자면, Spring boot container 였다면 아래와 같이 나왔을 것이다. $ kubectl logs Calculating JVM memory based on 14121456K available memory Calculated JVM Memory Configuration: -XX:MaxDirectMemorySize=10M -Xmx13524609K -XX:MaxMetaspaceSize=84846K -XX:ReservedCodeCacheSize=240M -Xss1M (Total..
이 글은 쿠버네티스 공식문서의 '로깅 아키텍처'를 바탕으로 요약 및 생각정리를 한 글 입니다. 잘못된 부분이 있다면, 자유롭게 피드백 부탁드립니다 :) 더 자세한 내용이 보고 싶으시다면, 아래 공식문서를 참고해주세요. 로깅 아키텍처 애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케 kubernetes.io 컨테이너 엔진들도 로깅을 지원하도록 설계되었다 → 표준 출력, 표준 에러 스트림 작성 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. 예를 들어, 컨테이너가 crash 되거나, Pod가 축출되거나, Node가 종료된 경우에..
- Total
- Today
- Yesterday
- MySQL
- 클린 아키텍처
- Spring boot
- java
- Spring
- hexagonal architecture
- Log
- c++
- 쿠버네티스
- Clean Architecture
- 로그
- 비동기
- WebFlux
- jasync
- Intellij
- boj
- python
- Istio
- 일상
- HTTP
- docker
- 하루
- Kubernetes
- 알고리즘
- Algorithm
- 백준
- container
- gradle
- tag
- k8s
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |