[인프런 워밍업 클럽 4기] DevOps 발자국 4주차 - 일프로 부족할때 (TS러버)

1. Argo CD (Continuous Delivery)GitOps 기반 배포 도구Git 저장소에 있는 Kubernetes manifest를 지속적으로 감시Git의 Desired 상태와 클러스터의 Live 상태 간의 diff를 감지하여 Sync(동기화) 수행핵심 구성요소:Server: 웹 UI & CLI용 API 서버Repo Server: Git에서 manifest 읽어오기Application Controller: manifest 차이 비교 및 동기화KubeAPI: K8s 리소스와 통신Redis: 캐시 저장소Dex: SSO 등 외부 인증 연동2. Argo Image Updater도커 이미지의 태그 변경을 감지하여 ArgoCD에 자동 Sync 요청Helm 또는 Kustomize 기반의 ArgoCD 앱과 연동해야 함ArgoCD 앱과 Docker Registry 정보를 설정하여 자동 배포 가능3. Argo WorkflowsKubernetes 네이티브의 워크플로우 매니지먼트 툴Airflow / Kubeflow 같은 도구와 유사복잡한 배치 작업, ML 파이프라인 실행 등에 적합4. Argo EventsKafka 등과 연결 가능한 이벤트 기반 트리거 시스템Argo Workflow나 다른 시스템을 특정 이벤트 발생 시 자동 실행 가능5. Argo RolloutsArgoCD 없이도 단독 사용 가능K8s Deployment를 확장하여 고급 배포 전략 제공지원 배포 방식:Blue-Green: 프리뷰 환경 만들고, 트래픽 전환Canary: 설정된 step에 따라 점진적 트래픽 이동Service를 자동으로 연결/해제하며 배포 안정성 확보CRD를 기반으로 설정회고요약이번 주는 Argo의 전체 그림과 각 도구의 역할을 연결지어 이해한 소중한 시간이었다.실습이 부족했던 점은 아쉽지만, 개념 정리에 집중한 덕분에 뼈대를 잡을 수 있었다.다음 주는 실습 위주로 구체적인 사용 경험을 쌓는 것을 목표로 삼고 싶다.

[인프런 워밍업 클럽 4기] - [미션6] ArgoCD로 자동 배포 흐름

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 복습을 위한 자료 입니다.강의 링크 :https://inf.run/f2xSRArgo CD Image Updater를 이용한 이미지 자동 배포 1. ArgoCD로 App 생성 및 배포 - 2232-build-push-git1-1. App 생성 하기 - [+ NEW APP] 클릭▶ GENERALApplication Name : api-tester-2232-build-push-git Project Name : default SYNC POLICY : Manual ▶ SOURCE※ 은 본인의 Username으로 수정Repository URL : https://github.com/tkdals5846/kubernetes-anotherclass-sprint2.git Revision : main Path : 2232-build-push-git/deploy/helm/api-tester▶ DESTINATIONCluster URL : https://kubernetes.default.svc Namespace : anotherclass-223▶ HELM 확인 후 Values files 지정VALUES FILES : values-dev.yaml ▶ 화면 상단 [CREATE] 클릭​1-2. 자동 배포 설정 - api-tester-2232-build-push-git > details > SYNC POLICY1-3. 자동 배포 확인 - ArgoCD 상태 및 Dashboard Pod 생성 유무2. Jenkins에 Github Token 등록2-1. Github에서 Credential 확인▶ GitHub → Settings▶ Developer settings : 왼쪽 메뉴 가장 하단에 위치▶ Personal access tokens (classic) 선택 후 [Generate new token] ▶ 권한 설정Note : Update for Jenkins Expiration : No expiration Select scopes : repo [체크]▶ 생성 후 발급된 키를 별도로 보관2-2. Jenkins에 Credential 등록▶ Dashboard > Jenkins 관리 > Credentials > System > Global credentials (unrestricted) 에서 [Add Credentials] 클릭 후 아래 내용 입력Kind : Username with password Scope : Global Username : Password : ID : github_token Description : Github 업데이트 토큰2-3. Jekninsfile 에서 Credential 사용 확인2232-build-push-git > Jenkinsfiledef valuesFile = "./${CLASS_NUM}/deploy/helm/api-tester/values-${params.PROFILE}.yaml" // image 수정 sh """ sed -i 's|^ repository:.*| repository: ${DOCKERHUB_USERNAME}/api-tester|' ${valuesFile} sed -i 's|^ tag:.*| tag: "${TAG}"|' ${valuesFile} """ // github로 업데이트 withCredentials([usernamePassword(credentialsId: 'github_token', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) { sh """ git config user.email "${GITHUB_USERNAME}@email.com" git config user.name "${GITHUB_USERNAME}" git remote set-url origin https://${USERNAME}:${PASSWORD}@github.com/${GITHUB_USERNAME}/kubernetes-anotherclass-sprint2.git git add ${valuesFile} git commit -m "Update ${valuesFile} with new image tag: ${TAG}" git push origin HEAD:main """ }3. Jeknins에서 Source/Container 빌드 후 Docker로 업로드 하기3-1.새보기 및 item 생성[새보기] 만들기 조회명 : 223 Type : List View [item name] 만들기 Enter an item name : 2232-build-push-git [Pipeline] 선택 [OK] 버튼 클릭3-2. Configure▶ Configure > General > GitHub project > Project url※ 은 본인의 Username으로 수정Project url : https://github.com//kubernetes-anotherclass-sprint2/▶ Configure > Advanced Project Options > Pipeline > [저장]※ 은 본인의 Username으로 수정Definition : Pipeline script from SCM Definition > SCM : Git Definition > SCM > Repositories > Repository URL : https://github.com//kubernetes-anotherclass-sprint2.git Definition > SCM > Branches to build > Branch Specifier : */main Definition > SCM > Branches to build > Additional Behaviours > Sparse Checkout paths > Path : 2232-build-push-git Definition > Script Path : 2232-build-push-git/Jenkinsfile3-3.[저장] 후 [지금 빌드] 실행 (이때는 파라미터가 없어서 실행되지 않아요!)3-4.[파라미터와 함께 빌드] 선택 후 본인의 DockerHub와 Github의 Username 입력 후 [빌드] 실행 3-5.Stage View결과 확인3-6. ArgoCD에서 자동 배포 확인3-7. 다시 빌드 후 재확인

[인프런 워밍업 클럽 4기 - DevOps] [미션5]컨테이너 이미지 사례 실습

컨테이너 이미지 사례 실습 ▶ 사전 준비사항# 도커 파일 및 App 소스 다운로드 curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/etc/docker/Dockerfile curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/etc/docker/hello.js [root@cicd-server ~]# ls Dockerfile hello.js1. docker build -t 1pro/hello:1.0.0 . 2. docker image list 3. docker tag 1pro/hello:1.0.0 1pro/hello:2.0.0 4-1. docker login -u 1pro 4-2. docker push 1pro/hello:1.0.0 5. docker rmi 1pro/hello:1.0.0 6. docker pull 1pro/hello:1.0.0 7. docker save -o file.tar 1pro/hello:1.0.0 8. docker load -i file.tar 1. 빌드2. 이미지 리스트 조회3. 태그 변경4-1. 로그인4-2. 이미지 업로드5. 이미지 삭제6. 이미지 다운로드7. 이미지 -> 파일로 변환▶ 이미지 삭제8. 파일 -> 이미지로 변환▶ 정리컨테이너디 (Containerd)1. ctr ns list 2. ctr -n k8s.io image list 3. ctr images pull docker.io/1pro/hello:1.0.0 4. ctr images tag docker.io/1pro/hello:1.0.0 docker.io/1pro/hello:2.0.0 5. ctr image push docker.io/1pro/hello:2.0.0 --user 1pro 6. ctr -n default image export file.tar docker.io/1pro/hello:1.0.0 7. ctr -n k8s.io image import file.tar 8. ctr -n k8s.io image remove docker.io/1pro/hello:1.0.0 1. 네임스페이스 조회2. 특정 네임스페이스 내 이미지 조회3. 다운로드 및 이미지 확인 (이미지는 default라는 네임스페이스에 다운 받아집니다.)4. 태그 변경5. 업로드6. 이미지 (namespace : default) -> 파일로 변환7. 파일 -> 이미지로 변환 (namespace : k8s.io)8. 삭제 (namespace : k8s.io)같은 이미지를 도커에서 받았을 때와 쿠버네티스에서 받았을 때 사이즈가 다른 이유▶ Docker Hub (248.26 MB)▶ Docker (520MB)▶ Containerd (247.8 MiB)1. Container Image를 만들 때 플랫폼(amd64, arm64)을 고려해야 되는데, Docker에서는 amd64를 받았고, Kuberentes에서 arm64를 받아서 이미지 크기가 달라졌을 것이다.▶ Docker Hub에 올라간 이미지는 amd64 [win, linux]과 arm64 [mac m series]을 지원▶ Docker (amd64가 보임)▶ Containerd (amd64, arm64)가 보임분석 :해당 Image는 Mac M 시리즈나 Window 유저가 모두 다운받을 수 있도록 만들었습니다. 그래서 한 Image에 amd64, arm64 버전이 각각 있는 거고요.현재 저는 Linux (adm64)에서 이미지를 다운로드를 실행 했고, Docker에서는 amd64 이미지를 받았고, Containerd에서는 amd64와 arm64 둘다 있는 걸로 보아 두 버전이 모두 사용가능한 이미지가 다운 받아진 것 처럼 느껴질 수 있습니다.그럼 두 버전을 모두 받은 Containerd 이미지가 더 커야 할 텐데, 오히려 이미지가 더 작아요.​결론 :Containerd에서 PLATFORMS는 그냥 해당 이미지가 어떤 플랫폼을 지원하는지 정보를 보여준 것이지, 실제 여러 플랫폼에서 실행 가능한 이미지를 받았다는 의미는 아닙니다.내가 amd64 환경에서 다운로드 했다면, Containerd는 알아서 amd64의 이미지를 다운 받아와요.그렇기 때문에 Docker나 Containerd 에서는 같은 amd64 이미지를 다운받았고, 결국 Size도 같아야 합니다.​2. Container 이미지는 각각의 Layer로 구성돼 있는데, Docker에서 다운 받을 때는 전체 Layer를 받았고, Kubernetes에는 기존 이미지에 이미 존재하는 Layer가 있기 때문에 새로 받은 이미지의 Size가 작게 조회 됐을 것이다. ▶ Docker -> Containerd1. 파일로 변환2. 복사3. 이미지로 변환▶ Containerd -> Docker1. 파일로 변환2. 복사3. 이미지로 변환분석 :Docker의 이미지를 파일로 변경 했을 때는 이미지 사이즈가 약간 작아졌지만, 큰 차이가 없었고, 그 파일을 Containerd로 Import 했을 때 사이즈의 변화는 없었습니다.반면 Containerd의 이미지를 Docker로 넣었더니 이미지가 증가했네요.Docker로 다운 받나, Containerd로 다운 받나 어차피 같은 동작을 하는 이미지이고, 각각 최초 조회 되는 Size가 달랐어도, 이동되는 파일이나, Import 시에 파일 사이즈가 좀 이상해 보입니다.결론 :Container의 이미지는 Layer 방식으로 만들어지며, A 이미지가 1, 2, 3 레이어를 가지고 있고, 각 레이어의 크기가 1MB라고 했을 때, 1, 2, 3, 4 레이어를 가지진 B 이미지를 다운받는 다면, 4 레이어만 다운 받으면 되고B 이미지는 기존 A 이미지가 가지고 있는 1, 2, 3 레이어를 같이 사용하고, 거기에 4 레이어만 해서 자신의 이미지를 만듭니다.​그래서 A와 B의 이미지를 조회 할 때는, A-3MB, B-4MB로 보이지만, 내부적으로는 4MB만 사용을 해요. 컨테이너 이미지는 조회 권한만 있는 스냅샷이기 때문에 다른 이미지에서도 같이 레이어를 공유해서 사용할 수 있고, 거기에 내 레이어를 추가하는 방식으로 구성 됩니다. 그래서 필요한 레이어만 다운 받으면 되니 컨테이너가 Disk 자원적으로는 매우 유리한 거죠.​이런 관점에서 볼때, 위 그림에서 최초 조회된 사이즈 (Docker-490MB, Containerd-248.3MiB)는 내부적으로는 어떻게 사용되고 있는지 모르겠지만, 해당 이미지를 구성하는 전체 사이즈가 맞습니다.​그래서 결국 Docker에서 Containerd로 이미지를 가져갔을 때 Size가 그대로이고, 반대로 Containerd에서 Docker로 이미지를 가져갔을 때는 Size가 증가하는 원인을 찾아야 합니다. 3. 쿠버네티스에는 다른 Runtime을 사용했을 수 있고, 같은 이미지더라도 사용하는 Runtime에 따라서 이미지의 크기는 달라질 것이다.분석쿠버네티스는 Runtime으로 Docker나 Containerd 둘중 하나를 선택할 수가 있는데, 예전에는 주로 도커를 사용했지만 현재는 Contaienrd가 기본으로 사용되고 있다.이미지 사이즈가 다른 이유는 Docker와 Kubernetes가 아닌 Docker와 Contaienrd의 차이이다.결론Docker는 다른 많은 기능들을 지원해 주기 때문에 실제 이미지가 247.8 MiB라고 하더라도 다운 받은 이후 자신의 메타데이터 규격에 맞게 데이터들을 더 추가하고 이미지를 재구성한다. 그래서 520MB가 된 것이다. Containerd에서 이미지를 가져왔을 때도 마찬가지로, 이미지를 재구성 하느라 Size가 커졌다.반대로 Docker의 이미지를 Contaienrd로 가져가게 됐을 때, Docker에서 재구성을 하느라 커진 불필요한 메타데이터들이 그대로 들어간 것이다.꼭 알고 넘어가야 하는점인터넷이 연결되지 않는 환경에서는 이미지들을 다운 받아서 파일 형태로 복사를 해야된다.이때 쿠버네티스에서 Contaienrd를 사용한다면 Docker로 받은 이미지를 복사해 넣을 경우 불필요하게 이미지 사이즈가 커지게 됩니다.

[인프런 워밍업 클럽 4기] DevOps 발자국 3주차 - 일프로 부족할때 (TS러버)

강의 수강데브옵스 한방정리DevOps는 단순히 CI/CD를 구성하는 것을 넘어서, 운영과 개발을 잇는 사고방식임을 이해했습니다.CI/CD 자동화 환경에서 실행 파일 생성과 배포 파이프라인이 어떻게 연결되는지를 전체 흐름으로 익힐 수 있었습니다.손쉽게 데브옵스 환경을 구축하는 방법Jenkins를 통해 GitHub 소스를 자동 빌드하고, 쿠버네티스에 배포하는 전 과정을 실습했습니다.전역 환경 설정, 파이프라인 구성, 그리고 배포까지 이어지는 흐름을 따라가며 DevOps 툴의 연결 지점을 익혔습니다.배포를 시작하기 전에 반드시 알아야 할 것들기본적인 쿠버네티스 배포 외에도, 실제 서비스 운영 시 많이 활용되는 Blue/Green과 Canary 배포 전략을 학습했습니다.트래픽 전환을 위해 라벨과 셀렉터를 활용하며, 롤백이 쉬운 배포 구조를 직접 구성해보았습니다.Helm과 KustomizeKubernetes YAML을 템플릿화할 수 있는 Helm과 오버레이 중심의 Kustomize를 비교했습니다.Helm은 마치 ‘붕어빵 틀’처럼 재사용 가능한 구조를 만들 수 있어, 반복적인 배포에 유용하다는 점이 인상 깊었습니다.한주 후기Jenkins를 통해서 쿠버네티스에 배포하는 과정과 여러가지 배포전략 (롤링, Blue/Green, Canary)등을 학습했고 이후에 Kustomize배포와 ArgoCD를 사용하면 얼마나 더욱 편해지고 활용도가 높을지 기대가 되는것 같습니다. 3주차가 되니까 확실히 생업과 병행하는것이 상당히 힘들다는 생각이 들면서 다음주에는 이부분을 개선하기 위해서 노력해야 될것 같아요.

[쿠버네티스] 배포를 시작하기 전에 반드시 알아야 할것들 (TS러버)

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 복습을 위한 자료 입니다.강의 링크 :https://inf.run/f2xSR1. CI/CD 파이프라인을 구성할 때 고려해야 하는 요소 2. 배포 전략을 세울 때 고려해야 하는 요소3. 단계별로 구축해보는 배포 파이프라인

[쿠버네티스] 손쉽게 데브옵스 환경을 구축 하는 방법 (TS러버)

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 복습을 위한 자료 입니다.강의 링크 :https://inf.run/f2xSR1. CI/CD 서버환경을 구성하기

[쿠버네티스] 데브옵스(DevOps)한방 정리 (TS러버)

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 복습을 위한 자료 입니다.강의 링크 :https://inf.run/f2xSR1. 어나더 클래스 DevOps 전체 구성도개발 소스를 GitHub에 커밋하면 소스 코드를 통합적으로 관리를 하다가 CI-CD 환경에서 Build 버튼을 누르면 먼저 GitHub에서 최신 소스 코드가 다운받아집니다.Gradle로 소스빌드가 시작되는데, Maven 저장소에서 소스에 필요한 라이브러리들을 다운받는 과정이 있고 최종적으로 실행할 수 있는 형태릐 JAR파일이 만들어 지면서 소스빌드가 종료된다Kubernetes 환경으로 배포하기 위해 컨테이너 빌드를 해야하고 도커로 빌드가 시작되는 과정은 도커 허브에서 OpenJDK가 있는 베이스 이미지를 다운 받는다다운 받은 이미지에 내 JAR파일을 넣으면 앱이 컨테이너 이미지로 만들어진다이걸 도커 허브에 올려놓는다.배포를 위해서 kubctl 명령어를 날려서 kubernetes에 파드를 생성시키면Kubernetes가 필요한 이미지를 도커 허브에서 다운받고 ContainerD한테 컨테이너 생성을 요청내 앱이 실행된다.2. DevOps에서 가장 중요한 것 개발개발자가 개발빌드 실행 가능한 파일로 만들기 위한 과정Gradle로 빌드 하지만 컴파일 부분은 OpenJDK가 사용실행파일JAR라는 파일이 JVM위에서 실행됨. 3. DevOps를 구성하는 오픈소스들4. DevOps를 구성하는 오픈소스들연차가 쌓일수록 점차 범위를 넓혀가야 하고 만약 DevOps 엔지니어가 되더라도 개발을 꾸준히 해야한다.고연차로 넘어가면서 PM/PL/아키텍트/컨설턴트로 일할 수 있는 기회가 많이 생기는데 이때 높은 역량을 보여주기 위해서 알고 있는 범위가 많아야 한다.GitOps - git 하나로 통일하자DevSecOps - 빠른 배포와 보안을 동시에 잡자!MLOps - 머신러닝 (상품추천, 사용자 행동 예측)LLMOps - ChatGPT같은 방대한 규모에 특화FinOps - 클라우드 환경 비용 절감에 포커스

[인프런 워밍업 클럽 4기] DevOps 발자국 2주차 - 일프로 부족할때 (TS러버)

강의 수강1. Probe운영 복잡도를 줄이고무중단 배포와 장애 자가 복구를 실현하며회복탄력성 있는 시스템을 구축할 수 있게 해줍니다.Probe는 단순한 기능이 아니라 쿠버네티스가 추구하는 "자율 복구 기반 인프라"의 핵심 구성 요소입니다.2. ConfigMap, Secret배포 환경 전환이 쉬워지고민감 정보 보호가 강화되며유지보수와 운영 자동화가 수월해집니다.ConfigMap과 Secret은 단순 설정 리소스를 넘어서 쿠버네티스 애플리케이션 관리의 핵심 도구입니다.3. PV/PVC, Deployment, Service, HPAPV/PVC: 선언형 저장소 관리, 역할 분리 구조Deployment: 선언형 배포 및 자동 롤백Service: 고정된 통신 경로와 로드밸런싱HPA: 자동 스케일링, 고급 지표 연동 가능4. Component동작으로 이해하기Controller다른 리소스를 감시하고 상태를 유지/제어하는 역할 Object독립적으로 실행 자원으로 존재 리소스의 ScopeNamespace-level: 논리적으로 분리된 공간Cluster-level: 클러스터 전역에서 동작하는 리소스미션미션 2,3,4를 하면서 이전 심화 응용 미션을 한 후 설정값을 되돌리기 하지 않아서 다음 미션을 수행하는데 지장이 생겨 이를 해결하는 과정에서 시간이 조금 소요되었다. 그래도 오히려 카페에 나와있는 내용을 그대로 했을때 한번에 되는것보다 이렇게 디버깅 과정과 오류를 해결하는 과정이 더 재밌다고 생각이 들고 이게 더 오래 기억에 남는것 같다.http://192.168.56.30:31231/create-file-pv어라 왜 나는 랜덤 파일명이 리턴 받지 않는거지? 이유가 뭘까?Deployment yaml 까보기그라파나 Loki 로그 확인해보기 강사님 자바 코드 소스 분석해보기 - https://github.com/k8s-1pro/app/blob/main/src/main/java/com/pro/app/service/DefaultService.java이런식으로 디버깅 하는 과정이 결국 나를 좀 더 단단한 데브옵스 개발자로 성장 시켜주는게 아닌가 싶다.거의 6시간 정도 소요되었는데 이과정에서 다시 세팅해서 정상적으로 동작할 수 있게 도출하는 과정에서 좀 더 Probe, ConfigMap, Secret, PV/PVC, Deployment, Service, HPA에 대해서 이해가 잘되었다!

[인프런 워밍업 클럽 4기 - DevOps] [미션4]PVC/PV 응용과제

PVC/PV, Deployment, Service, HPA 응용 과제 1. PV, PVC 1~4. local 동작 확인// 2번 - Container 임시 폴더 확인 kubectl exec -n anotherclass-123 -it api-tester-1231-5d4f6454fb-28b8k -- ls /usr/src/myapp/tmp // 2번 - Container 영구저장 폴더 확인 kubectl exec -n anotherclass-123 -it api-tester-1231-5d4f6454fb-28b8k -- ls /usr/src/myapp/files/dev // 2번 - master node 폴더 확인 ls /root/k8s-local-volume/1231 // 3번 - Pod 삭제 [root@k8s-master ~]# kubectl delete -n anotherclass-123 pod api-tester-1231-5d4f6454fb-28b8k4번 API - 파일 조회1-2. hostPath 동작 확인 - Deployment 수정 후 [1~4] 실행 spec: volumes: - name: files hostPath: path: /root/k8s-local-volume/1231 - name: secret-datasource secret: secretName: api-tester-1231-postgresql defaultMode: 420[1~4]확인// 1번 API - 파일 생성 http://192.168.56.30:31231/create-file-pod http://192.168.56.30:31231/create-file-pv // 2번 - Container 임시 폴더 확인 [root@k8s-master ~]# kubectl exec -n anotherclass-123 -it api-tester-1231-7b47f86c96-pklt9 -- ls /usr/src/myapp/tmp // 2번 - Container 영구저장 폴더 확인 [root@k8s-master ~]# kubectl exec -n anotherclass-123 -it api-tester-1231-7b47f86c96-pklt9 -- ls /usr/src/myapp/files/dev // 2번 - master node 폴더 확인 [root@k8s-master ~]# ls /root/k8s-local-volume/1231 // 3번 - Pod 삭제 [root@k8s-master ~]# kubectl delete -n anotherclass-123 pod api-tester-1231-7b47f86c96-pklt9 // 4번 API - 파일 조회 http://192.168.56.30:31231/list-file-pod http://192.168.56.30:31231/list-file-pv 2. Deployment2-1. RollingUpdate 하기 kubectl set image -n anotherclass-123 deployment/api-tester-1231 api-tester-1231=1pro/api-tester:v2.0.0배포 되는동안 2개의 버전이 공존함 2-2. RollingUpdate (maxUnavailable: 0%, maxSurge: 100%) 하기 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0% maxSurge: 100%2개의 버전이 공존하지 않음 2-3. Recreate 하기 strategy: type: Recreate배포중 서비스 중단 2-4. Rollback버전 v1.0에서 v2.0으로 롤백 성공 3. Service3-1. Pod 내부에서 Service 명으로 API 호출 [서비스 디스커버리]3-2. Deployment에서 Pod의 ports 전체 삭제, Service targetPort를 http -> 8080으로 수정// Deployment containers: - name: api-tester-1231 image: 1pro/api-tester:v2.0.0 envFrom: - configMapRef: name: api-tester-1231-properties // Service spec: ports: - protocol: TCP port: 80 targetPort: 8080 nodePort: 31231 4. HPA - search4-1. 부하 발생 4-2. [behavior] 미사용으로 적용

[인프런 워밍업 클럽 4기 - DevOps] [미션3]Configmap,Secret응용과제

1. Configmap의 환경변수들을 Secret을 사용해서 작성하고, App에서는 같은 결과가 나오도록 확인해 보세요 Step1. Secret 생성 (1) - dashboardapiVersion: v1 kind: Secret metadata: namespace: anotherclass-123 name: api-tester-1231-properties labels: part-of: k8s-anotherclass component: backend-server name: api-tester instance: api-tester-1231 version: 1.0.0 managed-by: dashboard stringData: spring_profiles_active: "dev" application_role: "ALL" postgresql_filepath: "/usr/src/myapp/datasource/dev/postgresql-info.yaml"Step2. Deployment의 envFrom.secretRef 부분 업데이트 containers: - name: api-tester-1231 image: 1pro/api-tester:v1.0.0 ports: - name: http containerPort: 8080 protocol: TCP envFrom: - secretRef: name: api-tester-1231-properties 2. 반대로 Secret의 DB정보를 Configmap으로 만들어보고 App을 동작시켜 보세요 apiVersion: v1 kind: ConfigMap metadata: namespace: anotherclass-123 name: api-tester-1231-postgresql labels: part-of: k8s-anotherclass component: backend-server name: api-tester instance: api-tester-1231 version: 1.0.0 managed-by: dashboard data: postgresql-info.yaml: | driver-class-name: "org.postgresql.Driver" url: "jdbc:postgresql://postgresql:5431" username: "dev" password: "dev123" 컨피드맵 생성확인Deployment의 volumeMounts.name과 volumes 부분 업데이트containers: - name: api-tester-1231 image: 1pro/api-tester:v1.0.0 ports: - name: http containerPort: 8080 protocol: TCP envFrom: - secretRef: name: api-tester-1231-properties resources: limits: cpu: 200m memory: 200Mi requests: cpu: 100m memory: 100Mi volumeMounts: - name: configmap-datasource mountPath: /usr/src/myapp/datasource/dev spec: volumes: - name: configmap-datasource configMap: name: api-tester-1231-postgresql변경 확인cat /usr/src/myapp/datasource/dev/postgresql-info.yaml