인프런 워밍업 클럽 4기 DevOps - 응용과제 미션 6

​1-1. App 생성 하기1-2. 자동 배포 설정 1-3. 자동 배포 확인2. Jenkins에 Github Token 등록2-1. Github에서 Credential 확인3. Jeknins에서 Source/Container 빌드 후 Docker로 업로드 하기3-1.새보기 및 item 생성

인프런 워밍업 클럽 4기 DevOps - 4주차 발자국

이번 주 카테고리Helm과 Kustomize 비교하며 사용-2ArgoCD 빠르게 레벨업-1ArgoCD 빠르게 레벨업-2ArgoCD 빠르게 레벨업-3이번 주 회고이번 주는 다른 주차에 비해 학습 분량은 적었지만, 내용의 난이도는 훨씬 높았다. Helm과 Kustomize는 쿠버네티스 리소스를 템플릿화하거나 커스터마이징할 수 있는 도구로 알고 있었지만, 실제로 실습을 해보니 각 도구의 철학과 사용 방식이 달라 적응하는 데 시간이 걸렸다.ArgoCD는 GitOps라는 개념을 바탕으로 한 배포 도구로, 겉보기에는 UI도 잘 갖춰져 있어 쉬워 보였지만, 내부 구조와 동작 원리를 이해하려다 보니 예상보다 복잡했다. 특히, 실습을 따라 진행하면서 발생한 예상치 못한 동작이나 버그의 원인을 파악하는 과정은 단순히 기능을 익히는 수준을 넘어선 깊은 이해를 요구했다.이번 주는 "양보다 질"의 한 주였다. 적은 분량 속에 담긴 고밀도의 개념들을 소화하려다 보니 시간이 훨씬 더 많이 소요되었고, 단순히 따라하는 수준을 넘어서 각 도구의 역할, 차이점, 그리고 실전에서 어떻게 활용해야 할지를 끊임없이 고민하게 되었다.앞으로도 관련 문서와 다른 개발자들의 블로그, GitHub 예제들을 참고해 내용을 다듬고, 실습을 반복하면서 점점 더 깊이 있는 이해를 쌓아가야만 한다.

인프런 워밍업 클럽 4기 DevOps - 응용과제 미션 5

1. docker build -t uheejoon/hello:1.0.0.2. docker image list 3. docker tag uheejoon/hello:1.0.0 uheejoon/hello:2.0.04-1. docker login -u uheejoon4-2. docker push uheejoon/hello:1.0.05. docker rmi uheejoon/hello:1.0.06. docker pull uheejoon/hello:1.0.07. docker save -o file.tar uheejoon/hello:1.0.08. docker load -i file.tar1. ctr ns list 2. ctr -n k8s.io image list 3. ctr images pull docker.io/uheejoon/hello:1.0.04. ctr images tag docker.io/uheejoon/hello:1.0.0docker.io/uheejoon/hello:2.0.05. ctr image push docker.io/uheejoon/hello:2.0.0--user uheejoon6. ctr -n default image export file.tar docker.io/uheejoon/hello:1.0.07. ctr -n k8s.io image import file.tar 8. ctr -n k8s.io image remove docker.io/uheejoon/hello:1.0.0docker pull uheejoon/api-tester:v1.0.0ctr image pull docker.io/uheejoon/api-tester:v1.0.02

인프런 워밍업 클럽 4기 DevOps - 3주차 발자국

이번 주 카테고리데브옵스 한방 정리손쉽게 데브옵스 환경을 구축하는 방법배포를 시작하기 전에 반드시 알아야 할 것들Jenkins Pipeline (기초부터 Blue/Green까지)Helm과 Kustomize 비교하며 사용 - 1이번 주 회고이번 주는 DevOps의 핵심이라 할 수 있는 배포와 자동화에 대해 집중적으로 다뤘고, 마지막에는 Helm과 Kustomize를 비교하며 실제 배포 도구를 실습했다.솔직히 말하면, 이번 주차는 생각보다 훨씬 어렵고 시간도 많이 필요한 과정이었다. 어떻게든 따라가긴 했지만, 지금 당장 누가 내용을 정확히 이해했냐고 물어본다면 자신 있게 “그렇다”고 대답하기는 어렵다.아마 다음 주차도 일단 끝까지 해내고 나서, 2~3번 이상 복습하면서 처음부터 다시 따라가는 게 필요할 것 같다.특히 현재 실무에서도 쿠버네티스를 도입할 계획이 있기 때문에, DevOps 환경과 배포, 파이프라인에 대해서는 더 확실한 개념을 갖고 있어야 한다는 생각이 들었다.앞으로도 더 깊이 공부하면서, 실무에서도 자신 있게 다룰 수 있도록 꾸준히 복습하고 연습할 예정이다.

인프런 워밍업 클럽 4기 DevOps - 응용과제 미션 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 -- ls /usr/src/myapp/tmp // 2번 - Container 영구저장 폴더 확인 [root@k8s-master ~]# kubectl exec -n anotherclass-123 -it -- 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 // 4번 API - 파일 조회 http://192.168.56.30:31231/list-file-pod http://192.168.56.30:31231/list-file-pvdeployment▶ 1. RollingUpdate 하기// 1) HPA minReplica 2로 바꾸기 (이전 강의에서 minReplicas를 1로 바꿔놨었음) kubectl patch -n anotherclass-123 hpa api-tester-1231-default -p '{"spec":{"minReplicas":2}}' // 1) 그외 Deployment scale 명령 kubectl scale -n anotherclass-123 deployment api-tester-1231 --replicas=2 // 1) edit로 모드로 직접 수정 kubectl edit -n anotherclass-123 deployment api-tester-1231 // 2) 지속적으로 Version호출 하기 (업데이트 동안 리턴값 관찰) while true; do curl http://192.168.56.30:31231/version; sleep 2; echo ''; done; // 3) 별도의 원격 콘솔창을 열어서 업데이트 실행 kubectl set image -n anotherclass-123 deployment/api-tester-1231 api-tester-1231=1pro/api-tester:v2.0.0 ▶ 2. RollingUpdate (maxUnavailable: 0%, maxSurge: 100%) 하기kubectl edit -n anotherclass-123 deployment api-tester-1231 --- apiVersion: apps/v1 kind: Deployment metadata: namespace: anotherclass-123 name: api-tester-1231 spec: replicas: 2 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 25% -> 0% # 수정 maxSurge: 25% -> 100% # 수정▶ 3. Recreate 하기apiVersion: apps/v1 kind: Deployment metadata: namespace: anotherclass-123 name: api-tester-1231 spec: replicas: 2 strategy: type: RollingUpdate -> Recreate # 수정 rollingUpdate: # 삭제 maxUnavailable: 0% # 삭제 maxSurge: 100% # 삭제▶ 4. Rollbackkubectl rollout undo -n anotherclass-123 deployment/api-tester-1231 Service▶ 1. Pod 내부에서 Service 명으로 API 호출 [서비스 디스커버리]// Version API 호출 curl http://api-tester-1231:80/version▶ 2. Deployment에서 Pod의 ports 전체 삭제, Service targetPort를 http -> 8080으로 수정apiVersion: apps/v1 kind: Deployment metadata: namespace: anotherclass-123 name: api-tester-1231 spec: template: spec: nodeSelector: kubernetes.io/hostname: k8s-master containers: - name: api-tester-1231 ports: // 삭제 - name: http // 삭제 containerPort: 8080 // 삭제 --- apiVersion: v1 kind: Service metadata: namespace: anotherclass-123 name: api-tester-1231 spec: ports: - port: 80 targetPort: http -> 8080 // 변경 nodePort: 31231 type: NodePortHPA▶ 1. 부하 발생http://192.168.56.30:31231/cpu-load?min=3 // 3분 동안 부하 발생 ▶ 2. [behavior] 미사용으로 적용kubectl edit -n anotherclass-123 hpa api-tester-1231-default --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: namespace: anotherclass-123 name: api-tester-1231-default spec: behavior: # 삭제 scaleUp: # 삭제 stabilizationWindowSeconds: 120 # 삭제▶ 2. 부하 발생1. 부하 발생 API http://192.168.56.30:31231/cpu-load // 2분 동안 10개의 쓰레드로 80% 부하 발생 // default : min=2, thread=10▶ 2. 부하 확인 (kubectl)// 실시간 업데이트는 명령어로 확인하는 게 빨라요 kubectl top -n anotherclass-123 pods kubectl get hpa -n anotherclass-123 ▶ 2. 부하 확인 (grafana)// 성능 (Prometheus를 거쳐 오기 때문에 좀 표시가 늦습니다) Grafana > Home > Dashboards > [Default] Kubernetes / Compute Resources / Pod // Replica 보기 (Grafana Dashbaord에서 [Kubernetes / Horizontal Pod Autoscaler] 다운로드 Grafana > Home > Dashboards > New > Import 클릭 - Import via grafana.com 항목에 17125 입력 후 [Load] 클릭

인프런 워밍업 클럽 4기 DevOps - 응용과제 미션 3

​▶ 응용1 : Configmap의 환경변수들을 Secret을 사용해서 작성하고, App에서는 같은 결과가 나오도록 확인해 보세요.☞ Secret을 이렇게 사용하는 경우는 별로 보지 못했습니다. 여러가지 방법으로 Secret을 만들어본다는데 의의를 두시면 됩니다.secret 추apiVersion: 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" ▶ 응용2 : 반대로 Secret의 DB정보를 Configmap으로 만들어보고 App을 동작시켜 보세요☞ Configmap을 Volume에 연결해서 쓰는 케이스는 매우 많습니다. deployment 수정pod에 마운트 된 경로

인프런 워밍업 클럽 4기 DevOps - 응용과제 미션 2

▶ 응용1 : startupProbe가 실패 되도록 설정해서 Pod가 무한 재기동 상태가 되도록 설정해 보세요.(여러분들이 가장 많이 겪게될 Pod 에러입니다)namespace: anotherclass-123deployment: api-tester-1231startupProbe: httpGet: path: /startup port: 8080 scheme: HTTP timeoutSeconds: 1 periodSeconds: 5 successThreshold: 1 failureThreshold: 1 # 여기를 낮게 수정결과: ▶ 응용2 : 일시적 장애 상황(App 내부 부하 증가)가 시작 된 후, 30초 뒤에 트래픽이 중단되고, 3분 뒤에는 App이 재기동 되도록 설정해 보세요.(아래 API를 날리면 readinessProbe와 livenessProbe가 동시에 실패하게 됩니다)// 부하 증가 API - (App 내부 isAppReady와 isAppLive를 False로 바꿈) curl http://192.168.56.30:31231/server-load-on // 외부 API 실패 curl http://192.168.56.30:31231/hello // 부하 감소 API - (App 내부 isAppReady와 isAppLive를 True로 바꿈) curl http://192.168.56.30:31231/server-load-offlivenessProbe과 readinessProbe을 다음과 같이 수정livenessProbe: httpGet: path: /liveness port: 8080 scheme: HTTP timeoutSeconds: 1 periodSeconds: 60 successThreshold: 1 failureThreshold: 3 readinessProbe: httpGet: path: /readiness port: 8080 scheme: HTTP timeoutSeconds: 1 periodSeconds: 10 successThreshold: 1 failureThreshold: 3결과:​▶ 응용3 : Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요.(꼭 API를 날리는 것만이 readinessProbe 활용의 전부는 아닙니다) readinessProbe을 다음과 같이 수정readinessProbe: exec: command: ["cat", "/usr/src/myapp/datasource/postgresql-info.yaml"] periodSeconds: 10 failureThreshold: 3결과: 없는 경로를 지정할 경우

인프런 워밍업 클럽 4기 DevOps - 2주차 발자국

전체적으로 느낀 점Kubernetes는 단순히 "컨테이너를 관리하는 도구"가 아니라, 전체 인프라의 상태를 코드로 정의하고 자동화하는 시스템이라는 걸 알게 되었다. 복잡하게 보였던 구성 요소들이 실제로는 잘 분리된 역할을 가지고 있다는 점이 인상 깊었고, 배울수록 실전에서 유용하겠다는 확신이 들었다. 배운 내용 요약 컨트롤 플레인과 클러스터 구조Control Plane은 클러스터의 두뇌로, 모든 오브젝트를 정의하고 감시하고 조율한다.etcd는 상태 저장소, Scheduler는 파드를 노드에 배치, Controller Manager는 상태를 지속적으로 유지.워커 노드는 kubelet, kube-proxy, containerd 등의 구성 요소로 작동하며, 컨테이너 실행은 Kubernetes가 직접 하는 게 아니라 런타임에게 요청한다는 구조가 흥미로웠다. 오브젝트 vs 컨트롤러오브젝트는 Pod, Service, PVC, ConfigMap처럼 기능 단위의 리소스컨트롤러는 이들을 자동화·유지·복구하는 역할 (Deployment, HPA 등)두 개념을 명확히 나눈 덕분에 Kubernetes의 확장성과 유연성이 보였다. ConfigMap과 SecretConfigMap: 설정값을 파드 외부에서 관리 → 환경별로 유연하게 구성 가능Secret: 민감정보 저장 (Base64 인코딩, 메모리 마운트)특히 Secret이 노드 메모리에 저장되고, 수정 시 kubelet이 주기적으로 반영하는 구조는 실제 운영환경에서 고려할 보안 요소가 많다는 걸 보여줌 Service서비스는 파드 IP가 변해도 고정된 접근점을 제공하는 추상화 계층ClusterIP, NodePort, LoadBalancer, ExternalName 타입마다 용도가 다르고,내부 DNS 기반의 이름 접근(서비스 디스커버리)은 마이크로서비스 아키텍처의 핵심 Probe (Liveness, Readiness, Startup)컨테이너가 살아있는지(Liveness), 준비됐는지(Readiness), 시작 중인지(Startup) 체크 가능Kubernetes가 단순 배포 도구가 아닌, 운영과 회복 기능까지 내장하고 있다는 걸 실감함설정에 따라 서비스 유입 제한, 자동 재시작 등 운영자가 손 쓸 필요 없는 자동화 처리가 가능 HPA (Horizontal Pod Autoscaler)설정된 기준(CPU 등)에 따라 파드 수를 자동으로 조절이상적인 스케일링과 현실적인 지연 시나리오를 비교하면서, HPA는 전능한 도구가 아니라 보조적인 수단임을 인지하게 됨

인프런 워밍업 클럽 4기 DevOps 미션 1

1-1 내 PC 네트워크 확인1-2 내 PC 자원 확인1-3 VirtualBox 설치 버전 확인1-4 Vagrant 설치 버전 확인[1-5] 원격접속(MobaXterm) 설치 버전 확인 -> 사용하던 Putty 그대로 사용 [2-1] VirtualBox VM 확인[2-2] 내 VM에 적용된 NAT 확인[2-3] 내 VM에 적용된 Host-Only Network 확인[2-4] VirtualBox Host-Only cidr 확인[3-1] Rocky Linux 버전 확인Hostname 확인[3-3], [3-4] Network 확인[3-5] 자원(cpu, memory) 확인▶ 타임존 설정 확인[root@k8s-master ~]# timedatectl[5] kubeadm 설치 전 사전작업▶ 방화벽 해제 확인[root@k8s-master ~]# systemctl status firewalld▶ 스왑(swap) 비활성화 확인[root@k8s-master ~]# free [root@k8s-master ~]# cat /etc/fstab | grep swap[6] 컨테이너 런타임 설치▶ iptables 세팅# 설정 세팅 확인 [root@k8s-master ~]# cat /etc/modules-load.d/k8s.conf [root@k8s-master ~]# cat /etc/sysctl.d/k8s.conf # 모듈 적제 확인 [root@k8s-master ~]# lsmod | grep overlay [root@k8s-master ~]# lsmod | grep br_netfilter▶ docker repo 설정 확인[root@k8s-master ~]# yum repolist enabled▶containerd 설치 확인[root@k8s-master ~]# systemctl status containerd▶설치 가능한 버전의 containerd.io 리스트 확인[root@k8s-master ~]# yum list containerd.io --showduplicates | sort -r▶ cri 활성화 설정 확인[root@k8s-master ~]# cat /etc/containerd/config.toml▶ kubelet cgroup 확인 (configmap)[root@k8s-master ~]# kubectl get -n kube-system cm kubelet-config -o yaml[7] kubeadm 설치▶ repo 설정 확인[root@k8s-master ~]# yum repolist enabled▶ SELinux 설정 확인[root@k8s-master ~]# cat /etc/selinux/config [root@k8s-master ~]# sestatus▶ kubelet, kubeadm, kubectl 패키지 설치#버전 보기 [root@k8s-master ~]# kubeadm version [root@k8s-master ~]# kubectl version #상태 보기 [root@k8s-master ~]# systemctl status kubelet #설정 파일 위치 [root@k8s-master ~]# cat /var/lib/kubelet/config.yaml #로그 조회 journalctl -u kubelet | tail -10▶ 설치 가능한 버전의 kubeadm 리스트 확인[root@k8s-master ~]# yum list --showduplicates kubeadm --disableexcludes=kubernetes[8] kubeadm으로 클러스터 생성▶ 클러스터 상태 확인# master node 상태확인 [root@k8s-master ~]# kubectl get node # pod network cidr 설정 확인 [root@k8s-master ~]# kubectl cluster-info dump | grep -m 1 cluster-cidr # apiserver advertise address 적용 확인 [root@k8s-master ~]# kubectl cluster-info # kubernetes component pod 확인 [root@k8s-master ~]# kubectl get pods -n kube-systemkubectl 사용 설정▶ 인증서 설정 확인[root@k8s-master ~]# cat ~/.kube/configCNI Plugin 설치 (calico)▶ calico pod 설치 및 pod network cidr 적용 확인# Calico Pod 상태 확인 [root@k8s-master ~]# kubectl get -n calico-system pod [root@k8s-master ~]# kubectl get -n calico-apiserver pod # Calico에 pod network cidr 적용 확인 [root@k8s-master ~]# kubectl get installations.operator.tigera.io default -o yaml | grep cidr▶ Master Node에 Taint 해제 확인[root@k8s-master ~]# kubectl describe nodes | grep Taints[9] 쿠버네티스 편의 기능 설치▶ kubectl 기능 설정 확인[root@k8s-master ~]# cat ~/.bashrc▶ dashboard 설치 확인[root@k8s-master ~]# kubectl get pod -n kubernetes-dashboard▶ metrics server 설치 확인[root@k8s-master ~]# kubectl get pod -n kube-system | grep metrics [root@k8s-master ~]# kubectl top pod -A

인프런 워밍업 클럽 4기 DevOps - 1주차 발자국

배운 개념 요약네임스페이스쿠버네티스 리소스를 논리적으로 구분해 관리하기 위한 단위실습 중 네임스페이스를 활용해 강의별 리소스를 격리해 관리한 것이 특히 인상 깊었음삭제 시 모든 내부 오브젝트도 삭제되지만 PV는 클러스터 레벨이라 별도 관리 필요디플로이먼트, 레플리카셋, 파드디플로이먼트 생성 → 내부적으로 레플리카셋 생성 → 파드 복제본 유지이름 지정 방식, 라벨-셀렉터의 역할을 실습하며 자연스럽게 익힘파드가 죽으면 자동 재생성되는 구조에서 쿠버네티스의 자가치유 개념을 체감함 컨테이너 설정 및 ENV 구성ConfigMap과 Secret을 사용한 환경 변수 주입 방식이 매우 유연하다는 인상실무에서 .env를 쿠버네티스에서는 어떻게 대체하는지를 명확히 이해함 프로브(Probe)스타트업/레디니스/라이브니스 프로브의 차이점을 실습을 통해 구체적으로 파악특히 Readiness Probe가 실패하면 트래픽을 차단하는 방식이 운영 환경에서 유용하다고 느낌 볼륨(PV/PVC)과 마운트PV는 클러스터에서 생성, PVC는 네임스페이스에서 요청둘 사이 연결을 셀렉터로 명확히 지정해야만 동작한다는 점을 실습으로 확인서비스(Service)파드와 클라이언트를 연결하는 핵심 요소라벨-셀렉터를 통해 다이나믹하게 연결된다는 점이 매우 직관적이고 강력HPA (Horizontal Pod Autoscaler)실습을 통해 CPU 부하에 따라 자동으로 파드 수를 조정하는 과정을 경험단순히 개수만 조정하는 게 아니라, 쿨타임(600초)을 두어 확장을 제어하는 구조까지 확인함느낀 점쿠버네티스는 단순히 "배포 도구"가 아니라, 운영에 최적화된 추상화 플랫폼이라는 인식을 하게 되었다.초반에는 오브젝트 간의 관계가 복잡해 보였지만, 실습을 반복하며 레이블과 셀렉터를 중심으로 이해하면 구조가 단순해진다는 점을 깨달음각 오브젝트는 독립적인 것처럼 보이지만 사실은 서로 긴밀히 연결된 구조이며, 이 연결을 정확히 설계해야 안정적인 운영이 가능하다는 점을 실감