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

[ 워밍업 클럽 4주차 회고 ]Helm에서 ArgoCD까지, 배포 자동화의 진화 이번 주는 쿠버네티스 패키지 관리와 GitOps의 세계로 본격 진입한 시간이었다. 단순한 kubectl apply에서 벗어나 '지속 가능한 배포'가 무엇인지 체감할 수 있었던 소중한 일주일이었다. Helm과 Kustomize - 패키지 관리의 두 가지 철학18강에서 다룬 Helm과 Kustomize 비교는 정말 인상 깊었다. 같은 목적을 가지고 있지만 접근 방식이 완전히 다른 두 도구를 직접 써보니, 각각의 철학이 확실히 드러났다.Helm은 '차트'라는 패키지 개념으로 재사용성에 집중했고, values.yaml을 통한 환경별 설정 관리가 직관적이었다.Kustomize는 기존 YAML을 건드리지 않고 overlay로 확장하는 방식이 더 쿠버네티스 네이티브하게 느껴졌다.특히 Helm 배포 실습에서 패키지 설치/업그레이드/롤백이 한 줄 명령어로 가능한 부분은 정말 강력했다. 하지만 Kustomize의 심플함도 매력적이었다. 결국 "팀의 상황과 프로젝트의 복잡도에 따라 선택하는 것"이 핵심이라는 걸 깨달았다. ArgoCD와의 첫 만남 - GitOps의 실체19강 ArgoCD 패키지 레벨업은 이번 주 하이라이트였다. 지금까지 배웠던 CI/CD가 'Push' 방식이었다면, ArgoCD는 'Pull' 방식의 GitOps를 보여줬다.Git 저장소의 변경사항을 ArgoCD가 주기적으로 감지해서 클러스터 상태를 동기화하는 과정을 보면서, "배포의 책임을 누가 가져야 하는가"에 대한 새로운 관점을 얻었다. 더 이상 Jenkins에서 클러스터로 직접 배포하는 것이 아니라, Git이 Single Source of Truth가 되는 구조가 훨씬 안전하고 추적 가능하다는 점이 인상적이었다. ArgoCD 아키텍처부터 실전 배포까지ArgoCD 설치부터 Argo Apps 설정, 그리고 실제 배포까지의 전 과정을 따라가면서 GitOps의 전체 흐름을 체험할 수 있었다.Application CRD를 통한 배포 정의자동 동기화 vs 수동 승인Health Status와 Sync Status의 차이점Git 기반 배포 히스토리 추적이런 개념들이 실습을 통해 하나씩 명확해졌다. 특히 ArgoCD UI에서 배포 상태를 시각적으로 확인할 수 있는 부분은 기존 CLI 기반 배포와는 차원이 다른 경험이었다. Image Updater - 자동화의 완성새로운 이미지가 레지스트리에 푸시되면 자동으로 Git 저장소의 매니페스트를 업데이트하고, ArgoCD가 이를 감지해서 배포까지 자동으로 이어지는 완전한 자동화 파이프라인을 구현할 수 있다는 점이 감동적이었다.이제야 "진정한 CI/CD"가 무엇인지 이해했다. 단순히 빌드-테스트-배포를 자동화하는 것을 넘어, Git 커밋부터 프로덕션 배포까지의 전체 흐름이 하나로 연결되는 구조 말이다.Blue/Green과 Canary - 배포 전략의 실제Blue/Green 배포와 Canary 배포를 ArgoCD와 연동해서 구현하는 실습은 이론으로만 알고 있던 배포 전략들을 직접 경험할 수 있는 소중한 시간이었다.특히 Canary 배포에서 트래픽을 점진적으로 증가시키면서 메트릭을 모니터링하고, 문제가 생기면 자동으로 롤백하는 과정을 보면서 "실무에서는 이런 식으로 안전하게 배포하는구나"를 체감했다.실무 관점에서 본 일주일이번 주는 단순한 기술 습득을 넘어 "어떻게 하면 더 안전하고 효율적으로 서비스를 운영할 수 있을까"에 대한 깊은 고민을 하게 된 시간이었다.Helm차트를 직접 작성하고, ArgoCD로 GitOps를 구현하며, 다양한 배포 전략을 실습하는 과정에서 DevOps 엔지니어의 역할이 단순한 '배포 담당자'가 아닌 '서비스 안정성의 설계자'라는 것을 느꼈다.

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

[ 워밍업 클럽 3주차 회고 ]DevOps, 운영을 넘어 배포의 미학까지이번 주는 쿠버네티스와 DevOps의 경계를 넘나들며 실제 배포와 운영에 필요한 개념들을 본격적으로 다뤘다. ‘코드를 잘 짠다’에서 ‘서비스를 잘 운영한다’로 시야를 넓혀야 하는 시점이라는 걸 체감한 시간이었다. DevOps 한방 정리 – 다시 짚는 DevOps의 본질DevOps는 단순한 도구의 집합이 아니라, 개발과 운영을 잇는 철학이라는 점을 다시금 깨달았다. 강의 초반에 나왔던 “협업과 자동화, 그리고 빠른 피드백”이라는 키워드는 실무에서도 계속 떠오를 개념이었다.CI/CD 도구, IaC, 모니터링 등을 단순히 기술로만 접근하지 않고, 조직의 문제를 해결하는 도구로 바라보는 관점이 인상 깊었다. 손쉽게 DevOps 환경을 구축하는 방법 – 도구보다 구조로컬에서도 금방 구성할 수 있는 Git + Jenkins + Docker + Kubernetes 파이프라인을 따라 실습하면서, DevOps 환경 구축이 생각보다 가까운 일이라는 걸 느꼈다. 특히 Jenkins + Docker-in-Docker 환경에서의 트러블슈팅 과정은 값진 경험이었다.강사님의 조언처럼, 작게 시작해서 점차 확장하는 것이 DevOps 도입의 핵심이라는 것을 느꼈다. 배포를 시작하기 전에 반드시 알아야 할 것들배포는 코드가 완성된 이후의 마지막 단계가 아니라, 설계 초기부터 염두에 두어야 하는 과정임을 배웠다.버전 관리 전략rollback 대비config 분리보안 설정(Secret 관리)이러한 것들이 어떻게 배포 안정성과 연결되는지를 배운 파트였다. 실제로 ConfigMap과 Secret의 실무 사용법은 지금이라도 우리 프로젝트에 적용하고 싶을 Jenkins Pipeline - 기초부터 Blue/Green까지이번 주 가장 인상 깊었던 파트 중 하나. Jenkins의 Declarative Pipeline을 직접 구성하면서 CI/CD 파이프라인의 기본 흐름을 체득했다. checkout 부터 build, test, docker build, push, kubectl apply까지 이어지는 작업은 실제 서비스 배포와 크게 다르지 않았다.특히 Blue/Green 배포 전략을 Jenkins로 구현하는 실습은 흥미로웠다. 트래픽을 기존 서비스에서 신규로 안전하게 전환하는 과정을 직접 경험하면서, 무중단 배포의 핵심이 무엇인지 체감할 수 있었다. Helm과 Kustomize 비교하며 사용해보기Helm과 Kustomize는 쿠버네티스에서 반복적인 배포 작업을 어떻게 더 효율적으로 관리할 수 있는지를 보여주는 좋은 도구였다. Helm은 패키징과 버전 관리를 통해 ‘재사용 가능한 차트’를 만들 수 있고,Kustomize는 기존 YAML을 재구성해 환경별 관리에 용이했다.단순히 어떤 게 더 낫다가 아니라, “어떤 상황에서 어떤 도구를 선택할 것인가”가 중요한 포인트라는 강의의 메시지가 와닿았다. 실무 감각을 키워준 일주일이번 주는 실습이 단순한 따라 하기에서 벗어나, “왜 이렇게 하는가”를 고민하게 만드는 수준으로 심화되었다. 각 기술이 연결되어 배포-운영-모니터링의 흐름을 구성하는 구조가 점차 보이기 시작했다.또한, Jenkinsfile을 수정하고 helm/kustomize로 배포를 조절하는 흐름 속에서 DevOps 역할이 단순히 ‘자동화하는 사람’이 아닌, 시스템 안정성과 속도를 책임지는 사람이라는 점도 다시 생각하게 됐다. 다음 주를 준비하며이제는 쿠버네티스 위에서의 운영이 조금씩 익숙해지고 있다. 다음 주는 GitOps나 ArgoCD 등 더 높은 수준의 운영 자동화도 다룰 예정인데, 이번 주 내용을 기반으로 나만의 배포 전략을 설계해보는 것도 의미 있을 것 같다.“자동화는 결과이고, 그 이전엔 설계가 있다.”3주차를 지나며, 단순한 배포를 넘어 설계와 운영의 연결 고리를 깊이 고민하게 됐다.

[인프런 워밍업 클럽 4기] 미션 4. PVC/PV, Deployment 등 응용과제

1. PV, PVC - search▶ 1~4. local 동작 확인// 2번 - Container 임시 폴더 확인// 2번 - Container 영구저장 폴더 확인// 2번 - master node 폴더 확인▶ 5. hostPath 동작 확인 - Deployment 수정 후 [1~4] 실행// 2번 - Container 임시 폴더 확인// 2번 - Container 영구저장 폴더 확인// 2번 - master node 폴더 확인2. Deployment - search▶ 1. RollingUpdate 하기▶ 2. RollingUpdate (maxUnavailable: 0%, maxSurge: 100%) 하기 spec: replicas: 2 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 25% -> 0% # 수정 maxSurge: 25% -> 100% # 수정▶ 3. Recreate 하기 (기존 파드 없애고 한번에 교체)spec: replicas: 2 strategy: type: RollingUpdate -> Recreate # 수정 rollingUpdate: # 삭제 maxUnavailable: 0% # 삭제 maxSurge: 100% # 삭제 ▶ 4. Rollback kubectl rollout undo -n anotherclass-123 deployment/api-tester-12313. Service - search▶ 1. Pod 내부에서 Service 명으로 API 호출 [서비스 디스커버리] ▶ 2. Deployment에서 Pod의 ports 전체 삭제, Service targetPort를 http -> 8080으로 수정▶ 2. 그리고 다시 Pod 내부에서 Service 명으로 API 호출(새로 생성된 파드에서 실행) 4. HPA - search ▶ 1. 부하 발생▶ 1. 부하 확인

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

▶ 응용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"변경 지점. Deployment[기존. Pod 환경변수 참조 - ConfigMap] envFrom: - configMapRef: name: api-tester-1231-properties[변경. Pod 환경변수 참조 - Secret]envFrom: - secretRef: name: api-tester-1231-properties[결과] ▶ 응용2 : 반대로 Secret의 DB정보를 Configmap으로 만들어보고 App을 동작시켜 보세요☞ Configmap을 Volume에 연결해서 쓰는 케이스는 매우 많습니다.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] volumeMounts: - name: files mountPath: /usr/src/myapp/files/dev - name: secret-datasource volumes: - name: files persistentVolumeClaim: claimName: api-tester-1231-files - name: secret-datasource secret: secretName: api-tester-1231-postgresql defaultMode: 420[변경. Deployment의 volumeMounts.name 과 volumes 부분 업데이트]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 image: 1pro/api-tester:v1.0.0 volumeMounts: - name: configmap-datasource mountPath: /usr/src/myapp/datasource/dev volumes: - name: configmap-datasource configMap: name: api-tester-1231-postgresql[결과]

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

[실습 일부 캡쳐][ 워밍업 클럽 2주차 회고 ]Object 그 너머의 세계로1주차에서 쿠버네티스의 기본 아키텍처를 이해했다면, 이번 주는 본격적으로 Object의 세계에 발을 담그는 시간이었다. Pod, ReplicaSet, Deployment를 넘어서 Labels, Selector, Naming까지 - 드디어 쿠버네티스가 어떻게 리소스들을 체계적으로 관리하는지 보이기 시작했다.실습 포함 vs 실습 필수의 차이강사님이 중간중간 "■ 실습포함"과 "■ 실습" 표시를 구분해주신 것이 인상적이었다. 단순히 따라하는 실습이 아니라, 꼭 해봐야 하는 핵심 실습을 명확히 구분해주니 학습 우선순위를 정하는 데 도움이 되었다. 특히 Object 그 너머 이해하기 실습에서는 직접 yaml 파일을 작성하며 Labels과 Selector의 동작 원리를 체감할 수 있었다.Application 기능으로 이해하기 - Probe의 실용성Probe 파트에서 가장 큰 깨달음을 얻었다. 단순히 컨테이너가 실행된다고 해서 애플리케이션이 정상 동작하는 것은 아니라는 점. Liveness Probe, Readiness Probe, Startup Probe 각각의 역할을 이해하니 실무에서 왜 헬스체크가 중요한지 명확해졌다. 특히 "일시적인 장애 상황에서의 프로브 활용" 강의는 실제 운영 환경에서 마주칠 수 있는 시나리오들을 미리 경험해볼 수 있어서 유익했다.Configmap과 Secret - 설정 관리의 철학애플리케이션 코드와 설정을 분리한다는 12 Factor App의 원칙을 쿠버네티스에서 어떻게 구현하는지 배웠다. 특히 "영역 파괴의 주범 Configmap" 강의 제목이 인상적이었는데, 실제로 잘못된 설정 관리가 어떤 장애를 일으킬 수 있는지 강사님의 실무 경험담을 들으니 더욱 신중하게 접근해야겠다는 생각이 들었다. Secret 기본 개념에서 이름 때문에 기대가 너무 컸다가, 실제로는 base64 인코딩 수준이라는 점을 알고 나서는 보안에 대해 더 깊이 생각해보게 되었다.스토리지의 복잡성과 PV/PVC의 우아함이번 주 가장 도전적이었던 부분은 스토리지 관리였다. 컨테이너는 Stateless하다고 배웠는데, 실제 애플리케이션에서는 데이터베이스, 로그, 파일 등 영속적인 데이터가 필요하다는 현실적인 문제. PV(Persistent Volume)와 PVC(Persistent Volume Claim)의 개념을 이해하니 쿠버네티스가 얼마나 잘 설계되었는지 감탄했다. 인프라 관리자는 PV로 스토리지 리소스를 제공하고, 개발자는 PVC로 필요한 만큼 요청하는 이 분리된 구조가 정말 깔끔하다.Deployment의 진짜 힘 - 무중단 배포지금까지 Deployment를 단순히 "ReplicaSet을 관리하는 상위 개념" 정도로만 생각했는데, 실제 배포 전략을 배우면서 생각이 완전히 바뀌었다. Rolling Update, Blue-Green, Canary 배포 전략을 실습해보니 실무에서 이런 기능들이 얼마나 중요한지 체감할 수 있었다. 특히 롤백 기능은 정말 마법 같았다. kubectl rollout undo 한 줄로 이전 버전으로 돌아갈 수 있다니!Service - 네트워킹의 핵심Pod은 언제든 죽고 새로 생성될 수 있는데, 그럼 클라이언트는 어떻게 애플리케이션에 접근할까? Service 개념을 배우면서 이 문제가 깔끔하게 해결되는 것을 보니 소름이 돋았다. ClusterIP, NodePort, LoadBalancer 각각의 용도를 이해하니 실무에서 어떤 상황에 무엇을 써야 할지 감이 잡히기 시작했다.HPA - 자동 스케일링의 마술마지막 HPA(Horizontal Pod Autoscaler) 부분이 가장 흥미로웠다. CPU 사용률이나 메모리 사용량에 따라 자동으로 Pod 수를 조절한다는 개념 자체가 신기했다. 클라우드 네이티브 환경에서 트래픽 변화에 자동으로 대응하는 이런 기능들이 있기 때문에 현대적인 애플리케이션 운영이 가능한 것 같다. 다만 아직 메트릭 서버 설정이나 세밀한 튜닝 부분은 더 연습이 필요할 것 같다.실무 관점에서의 통합적 사고이번 주 학습을 통해 쿠버네티스의 각 컴포넌트들이 어떻게 유기적으로 연결되어 있는지 보이기 시작했다. PVC로 데이터를 영속화하고, Deployment로 애플리케이션을 배포하고, Service로 네트워크를 연결하고, HPA로 자동 스케일링까지. 하나의 애플리케이션을 운영하기 위해 이 모든 것들이 어떻게 조화롭게 동작하는지 전체적인 그림이 그려지기 시작했다.앞으로의 각오벌써 2주차인데 쿠버네티스의 깊이를 조금씩 느끼고 있다. 각 개념들을 개별적으로 이해하는 것도 중요하지만, 실제 프로덕션 환경에서 어떻게 이들을 조합해서 안정적이고 확장 가능한 시스템을 만들어낼지 고민해보는 시간이 필요할 것 같다. 아직 모르는 것이 너무 많지만, 매일 조금씩 성장하고 있다는 느낌이 든다.

[인프런 워밍업 클럽 4기] 미션 2. Probe 응용과제

[미션 전 사전 준비]HPA minReplica 1로 바꿔서 Pod 1개로 진행[기존] Pod 2개 (HPA 2 -> Deployment 2)[변경] Pod 1개 (HPA 1 -> Deployment 1)HPA에 의해서 Pod 1개로 변경 ▶ 응용1 : startupProbe가 실패 되도록 설정해서 Pod가 무한 재기동 상태가 되도록 설정해 보세요.(여러분들이 가장 많이 겪게될 Pod 에러입니다) failureThreshold를 낮춰 빠르게 실패하도록 조정startupProbe: httpGet: path: /startup port: 8080 scheme: HTTP timeoutSeconds: 1 periodSeconds: 3 # 더 자주 체크 successThreshold: 1 failureThreshold: 3 # 3번만 실패해도 종료 ▶ 응용2 : 일시적 장애 상황(App 내부 부하 증가)가 시작 된 후, 30초 뒤에 트래픽이 중단되고, 3분 뒤에는 App이 재기동 되도록 설정해 보세요.readinessProbe: httpGet: path: /health port: 8080 periodSeconds: 5 failureThreshold: 6 # 5초 간격 * 6번 실패 = **30초 후** 트래픽 중단 successThreshold: 1 timeoutSeconds: 1 livenessProbe: httpGet: path: /health port: 8080 periodSeconds: 10 failureThreshold: 18 # 10초 간격 * 18번 실패 = **180초 후(Pod 재시작)** successThreshold: 1 timeoutSeconds: 1 [30초 뒤 트래픽 중단][3분 뒤 App 재기동]17시 25분 트래픽 중단17시 28분 앱 재기동 (3분 뒤)▶ 응용3 : Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요.(꼭 API를 날리는 것만이 readinessProbe 활용의 전부는 아닙니다)readinessProbe: exec: command: - cat - /usr/src/myapp/datasource/postgresql-info.yaml timeoutSeconds: 1 periodSeconds: 5 successThreshold: 1 failureThreshold: 3 [체크][파일 확인] readinessProbe를 HTTP API 방식으로 할지, 아니면 파일 존재(또는 커맨드 실행 결과) 방식 차이[HTTP 방식]→ 애플리케이션이 HTTP로 /readiness에 200 OK 응답하면 Ready 상태API 응답은 서비스 레벨의 준비 상태를 확인readinessProbe: httpGet: path: /readiness port: 8080[exec 방식]→ 파일이 존재하고 열 수 있으면 Ready 상태파일 체크 등은 환경 구성 요소(Secret, 파일 등) 의 준비 상태 확인readinessProbe: exec: command: ["cat", "/usr/src/myapp/datasource/postgresql-info.yaml"]

[인프런 워밍업 클럽 4기] 미션 1. 쿠버네티스 설치 구간별 상태 확인

[설치 환경]칩 : Apple M1 Pro메모리 : 16GBmacOS : Sequoia 15.5가상플랫폼 : UTM [Sprint1]쿠버네티스 무게감 있게 설치하기 > 구간별 상태 확인 (1/2) [미션1][1-3] UTM 설치 버전 확인[2-1] UTM VM 확인[3-1] Rocky Linux 버전 확인[3-2] Hostname 확인[3-3], [3-4] Network 확인참고. enp0s1: 물리적 네트워크 인터페이스 (이더넷)[3-5] 자원(cpu, memory) 확인 [Sprint1]쿠버네티스 무게감 있게 설치하기 > 구간별 상태 확인 (2/2) [미션1][4] Rocky Linux 기본 설정 타임존 설정 확인[5] kubeadm 설치 전 사전작업방화벽 해제 확인스왑(swap) 비활성화 확인[6-1] 컨테이너 런타임 설치 전 사전작업iptables 세팅참고. iptables: 어떤 네트워크 트래픽을 허용하거나 차단할지 정의하는 규칙 체계[6-2] 컨테이너 런타임 (containerd 설치)[6-2-1] containerd 패키지 설치 (option2)[6-2-1-1] docker engine (containerd.io)만 설치docker repo 설정 확인containerd 설치 확인설치 가능한 버전의 containerd.io 리스트 확인[6-3] 컨테이너 런타임 (CRI활성화)CRI (Container Runtime Interface) 활성화 설정 확인은 Kubernetes에서 사용하는 컨테이너 런타임(containerd, CRI-O, Docker 등)이 kubelet과 통신 가능한지, 그리고 설정이 올바르게 되어 있는지를 점검하는 과정cri 활성화 설정 확인kubelet cgroup 확인 (configmap)kubelet cgroup 확인 (kubelet)[7] kubeadm 설치SELinux 설정 확인kubelet, kubeadm, kubectl 패키지 설치설치 가능한 버전의 kubeadm 리스트 확인[8] kubeadm으로 클러스터 생성[8-1] 클러스터 초기화 (Pod Network 세팅)클러스터 상태 확인[8-2] kubectl 사용 설정인증서 설정 확인[8-3] CNI Plugin 설치 (calico)calico pod 설치 및 pod network cidr 적용 확인[8-4] Master에 pod를 생성 할 수 있도록 설정Master Node에 Taint 해제 확인[9] 쿠버네티스 편의 기능 설치[9-1] kubectl 자동완성 기능kubectl 기능 설정 확인[9-2] Dashboard 설치dashboard 설치 확인[9-3] Metrics Server 설치metrics server 설치 확인

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

[ 강의 정보 ]강의명 : 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2[ 워밍업 클럽 1주차 회고 ]워밍업 클럽을 선택한 이유솔직히 말하면 혼자서는 강의를 끝까지 완주하기가 어려웠다. 평소 강의를 사놓고 미루는 습관이 있어서 워밍업 클럽의 체계적인 학습 방식이 큰 도움이 될 것 같았다. 매일 정해진 분량을 학습하고 미션을 수행하며 함께 성장하는 구조가 매력적이었다.DevOps 영역에 발을 담그게 된 배경백엔드 개발을 하면서 항상 "내가 만든 코드가 실제로 어떻게 배포되고 운영되는지" 궁금했다. Docker는 어느 정도 사용해봤지만, 컨테이너 오케스트레이션과 클라우드 네이티브 환경은 여전히 미지의 영역이었다. CNCF 연간 서베이에 따르면 전 세계 조직의 96%가 쿠버네티스를 이미 사용 중이거나 검토 중이라고 한다. 이런 현실을 보면서 더 이상 미룰 수 없다는 생각이 들었다.일프로 강사님의 실무 중심 접근법가장 인상 깊었던 것은 강사님의 경험 중심 설명 방식이다. 단순히 쿠버네티스 개념만 설명하는 것이 아니라 "기술의 흐름으로 이해하는 컨테이너"라는 관점에서 Linux → 컨테이너 → 쿠버네티스로 이어지는 기술 발전 과정을 보여주셔서 맥락을 이해하는 데 큰 도움이 되었다. 왜 이 기술이 필요했고, 어떤 문제를 해결하기 위해 만들어졌는지를 알 수 있었다.실습 환경 구축의 의미단순히 클라우드에서 제공하는 매니지드 서비스를 사용하는 것이 아니라, 직접 쿠버네티스 클러스터를 구축해보는 과정이 특히 의미있었다. 각 구성 요소가 어떤 역할을 하는지, 왜 이런 설정이 필요한지를 하나씩 확인해가며 설치하니 쿠버네티스의 내부 동작 원리를 이해하는 데 도움이 되었다. 실무에서는 보통 EKS나 GKE 같은 매니지드 서비스를 사용하겠지만, 기본기를 탄탄히 다지는 차원에서 좋은 경험이었다.학습한 핵심 내용들컨테이너 기술의 역사적 맥락: Unix → Linux → Container → Kubernetes로 이어지는 기술 발전 흐름쿠버네티스 아키텍처 이해: Master Node와 Worker Node의 역할, 각 컴포넌트들의 상호작용기본 오브젝트 개념: Pod, ReplicaSet, Deployment의 관계와 실제 활용 방법실무 관점의 운영 철학: 왜 쿠버네티스가 현대 애플리케이션 배포/운영에 필수가 되었는지아직은 쿠버네티스 전체 그림의 한 조각만 본 느낌이지만, 견고한 기초를 다지는 시간이었다. 앞으로 Service, Ingress, ConfigMap 등 더 복잡한 개념들을 배울 때 이번에 학습한 기초가 얼마나 도움이 될지 기대된다.