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

강의 수강학습 내용 요약Sprint 2 - 4주차 커리큘럼 완강4주차 관련 모든 복습 수행 완료학습 내용 회고ArgoCD를 처음 배우면서 아키텍처와 각 컴포넌트가 어떻게 동작하는지 배울 수 있었다.실무에서 존재하지만 사용해보지 못했던 ArgoCD를 직접 만져가며 새로운 배포를 진행할 수 있게 되었다.

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

강의 수강학습 내용 요약Sprint 2 - 3주차 커리큘럼 완강3주차 관련 모든 미션, 모든 복습 수행 완료학습 내용 회고Jenkins는 이미 잘 사용하는 툴이어서 빠르게 복습할 수 있었고, 따라서 Helm과 Kustomize에 집중했다.실무에서 Helm과 Kustomize를 사용할 일이 있는데, 그래서 조금 더 이해가 잘 되었고 의미있었다.미션해결 과정 요약친절히 설명되어 있는 미션을 따라 실습을 진행했다.잘못 작성되어 있던 미션 본 글의 명령어 예시를 확인하고, 카페에 댓글까지 남겨서 정확한 문서가 되는 데 기여했다.미션 해결 회고이미 어느 정도 알고 있던 Docker의 명령어들은 복습할 수 있는 계기가 되었다.처음 사용해보는 Containerd의 명령어는 한 번 쭉 따라하며 배워볼 수 있었다. 메타데이터 때문에 이미지 크기가 달라지는 점에 주의해야 한다는 것을 뼈저리게 배울 수 있었다.

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

Docker와 Containerd 명령 실습 도커 (Docker)▶ 사전 준비사항실습 시작1. 빌드이미지 리스트 조회태그 변경4-1. 로그인4-2. 이미지 업로드5. 이미지 삭제6. 이미지 다운로드7. 이미지 -> 파일로 변환▶ 이미지 삭제8. 파일 -> 이미지로 변환▶ 정리 컨테이너디 (Containerd)네임스페이스 조회특정 네임스페이스 내 이미지 조회다운로드 및 이미지 확인태그 변경업로드이미지 -> 파일로 변환파일 -> 이미지로 변환삭제같은 이미지를 도커에서 받았을 때와 쿠버네티스에서 받았을 때 사이즈가 다른 이유 ▶ 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 (arm64가 보임)▶ Containerd (amd64, arm64)가 보임 분석해당 Image는 Mac M 시리즈나 Window 유저가 모두 다운받을 수 있도록 만들어져 있다. 그래서 한 Image에 amd64, arm64 버전이 각각 존재한다.Containerd에서는 amd64와 arm64 둘 다 있는 걸로 보아 두 버전이 모두 사용가능한 이미지가 다운 받아진 것이라면, 두 버전을 모두 받은 Containerd 이미지가 더 커야 할 텐데, 오히려 이미지가 더 작다.결론Containerd에서 PLATFORMS는 그냥 해당 이미지가 어떤 플랫폼을 지원하는지 정보를 보여준 것이지, 실제 여러 플랫폼에서 실행 가능한 이미지를 받았다는 의미는 아니다.amd64 환경에서 다운로드 했다면, Containerd는 알아서 amd64의 이미지를 다운받아 온다.그렇기 때문에 Docker나 Containerd 에서는 같은 amd64 이미지를 다운받았고, 결국 Size도 같아야 한다.​따라서 만약 Docker는 amd64였고 Containerd는 arm64 환경에서 설치가 됐다면, 해당 이미지의 사이즈는 달라졌을 수 있으나 현재는 그게 정답은 아니다. 2. Container 이미지는 각각의 Layer로 구성돼 있는데, Docker에서 다운 받을 때는 전체 Layer를 받았고, Kubernetes에는 기존 이미지에 이미 존재하는 Layer가 있기 때문에 새로 받은 이미지의 Size가 작게 조회 됐을 것이다.▶ Docker -> Containerd파일로 변환복사이미지로 변환 ▶ Containerd -> Docker파일로 변환복사이미지로 변환분석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에서 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] 2주차 발자국

강의 수강학습 내용 요약Sprint 1 - 2주차 커리큘럼 완강2주차 관련 모든 미션, 모든 복습 수행 완료학습 내용 회고지난 주에 이해를 위해 Spring 1의 모든 강의를 이미 다 들었어서, 복습을 작성하면서 복습이 잘 되어 좋았다.배운 내용들을 실제 실무에서도 적용해 보았고, 배운 내용들이 정확하게 다 사용이 되어서 뿌듯했다.미션해결 과정 요약친절히 설명되어 있는 미션을 따라 실습을 진행했다.확인하기 위한 명령어나 대시보드 들을 찾아가며 캡처 후 제출했다.미션 해결 회고미션의 난이도가 어렵다기 보다는, 이를 증빙하고 제출하는 문서를 작성하는 게 쉽지 않았다.이번 주는 미션이 3개여서 힘들었는데, 남은 두 주 모두 1개씩만 수행하면 되어 복습만 잘 챙기면 될 것 같다.

[인프런 워밍업 클럽 4기 - DevOps] 미션 4. PV/PVC, Deployment등

1-1. PV, PVC - local동작 확인1-2. PV, PVC - hostPath 동작 확인대시보드 > 디플로이먼트 > 편집으로 아래 구문 수정, 기존 레플리카 셋 제거# spec > template > spec > volumes persistentVolumeClaim: # 제거 claimName: api-tester-1231-files # 제거 hostPath: # 추가 path: /root/k8s-local-volume/1231 # 추가동작 확인2-1. Deployment - RollingUpdateminReplica 2로 바꾸기동작 확인배포되는 동안 두 버전이 공존2-2. Deployment - RollingUpdate (maxUnavailable: 0%, maxSurge: 100%)대시보드 > 디플로이먼트 > 편집으로 아래 구문 수정# spec > strategy rollingUpdate: maxUnavailable: 0% maxSurge: 100%동작 확인블루 그린 배포와 비슷하게 버전이 한 번에 변경됨2-3. Deployment - Recreate대시보드 > 디플로이먼트 > 편집으로 아래 구문 수정# spec > strategy type: Recreate # 수정 rollingUpdate: # 삭제 maxUnavailable: 0% # 삭제 maxSurge: 100% # 삭제동작 확인배포 중 서비스 중단2-4. Deployment - Rollback동작 확인배포 중 서비스 중단3-1. Pod 내부에서 Service 명으로 API 호출 [서비스 디스커버리]대시보드 > 파드 > 새로 생성된 Pod에서 Exec3-2. Deployment에서 Pod의 ports 전체 삭제, Service targetPort를 http -> 8080으로 수정대시보드 > 디플로이먼트 > 편집으로 아래 구문 수정# spec > template > spec > containers ports: # 제거 - name: http # 제거 containerPort: 8080 # 제거 protocol: TCP # 제거대시보드 > 서비스 > 편집으로 아래 구문 수정# spec > ports targetPort: 8080 # 변경대시보드 > 파드 > 새로 생성된 Pod에서 Exec4. HPA부하 발생한 번에 하나 스케일링 확인kubectl edit -n anotherclass-123 hpa api-tester-1231-default# spec > behavior > scaleUp stabilizationWindowSeconds: 120 # 삭제부하 발생빠르게 최대로 스케일링 확인

[인프런 워밍업 클럽 4기 - DevOps] 미션 3. ConfigMap, Secret

▶ 응용1 : Configmap의 환경변수들을 Secret을 사용해서 작성하고, App에서는 같은 결과가 나오도록 확인해 보세요.대시보드 > 신규 리소스 생성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"대시보드 > 시크릿 확인대시보드 > 디플로이먼트 > 편집으로 아래 구문 수정, 기존 레플리카 셋 제거# spec > template > spec > containers envFrom: - secretRef: name: api-tester-1231-properties대시보드 > 파드 > 새로 생성된 Pod에서 Exec > 명령어를 통해 환경 변수 확인env ▶ 응용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"대시보드 > 컨피그 맵 확인대시보드 > 디플로이먼트 > 편집으로 아래 구문 수정, 기존 레플리카 셋 제거# spec > template > spec volumes: - name: configmap-datasource configMap: name: api-tester-1231-postgresql # spec > template > spec > containers volumeMounts: - name: configmap-datasource mountPath: /usr/src/myapp/datasource/dev대시보드 > 파드 > 새로 생성된 Pod에서 Exec > 명령어를 통해 파일 확인cat /usr/src/myapp/datasource/dev/postgresql-info.yaml

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

미션 전 사전 준비HPA minReplica 1로 바꿔서 Pod 1개로 진행 ▶ 응용1 : startupProbe가 실패 되도록 설정해서 Pod가 무한 재기동 상태가 되도록 설정해 보세요.대시보드 > 디플로이먼트 > 편집으로 아래 구문 수정, 기존 레플리카 셋 제거startupProbe: httpGet: path: "/startup" port: 8080 periodSeconds: 5 failureThreshold: 1 ▶ 응용2 : 일시적 장애 상황(App 내부 부하 증가)가 시작 된 후, 30초 뒤에 트래픽이 중단되고, 3분 뒤에는 App이 재기동 되도록 설정해 보세요.대시보드 > 디플로이먼트 > 편집으로 아래 구문 수정, 기존 레플리카 셋 제거readinessProbe: httpGet: path: "/readiness" port: 8080 periodSeconds: 10 failureThreshold: 3 livenessProbe: httpGet: path: "/liveness" port: 8080 periodSeconds: 60 failureThreshold: 3부하가 발생한 직후에는 API 요청이 성공하였으나, 30초 후 요청이 차단된 것 확인60초 간격으로 livenessProbe 3번 실패 후 App 재시작 확인 ▶ 응용3 : Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요.대시보드 > 디플로이먼트 > 편집으로 아래 구문 수정, 기존 레플리카 셋 제거readinessProbe: exec: command: ["cat", "/usr/src/myapp/datasource/postgresql-info.yaml"] periodSeconds: 10 failureThreshold: 3해당 파일은 존재하므로 실패 로그 확인 불가.

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

강의 수강학습 내용 요약Sprint 1 - 1주차 커리큘럼 완강1주차 관련 모든 미션 수행 완료학습 내용 회고복습에 시간을 많이 쏟았지만, 그만큼 잘 정리한 것 같고 공부가 잘 된 것 같다.Object 그려보며 이해하기 부분이 이해가 잘 안되어서 Sprint 1의 모든 강의를 다 듣고 다시 들으며 복습하니 이해가 잘 되었다.미션해결 과정 요약친절히 설명되어 있는 미션을 따라 실습을 진행했다.Mac 환경에 맞지 않는 미션이었어서, 질문 답변을 통해 확인하고 진행했다.미션 해결 회고확실히 따라 해보며 흐름을 이해하는 데 도움이 되었다.확실하지 않은 부분은 빠르게 질문 답변을 통해 확인 받고 진행하는 것이 좋은 것 같다.

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

참고 사항Mac-m시리즈에서 구동하였으므로 내 PC 자원은 Mac 기준,VM 관련 정보는 쿠버네티스 빠른설치 (Mac-m시리즈)를 기준으로 작성하였습니다.[1-1] 내 PC 네트워크 확인[1-2] 내 PC 자원 확인[1-3] UTM 설치 버전 확인[1-4] Termius 설치 버전 확인 (개인적으로 사용하는 터미널 앱)[2-1] UTM VM 확인[2-2] 내 VM에 적용된 네트워크 확인[3-1] Rocky Linux 버전 확인[3-2] Hostname 확인[3-3], [3-4] Network 확인[3-5] 자원(cpu, memory) 확인[4] Rocky Linux 기본 설정▶ 타임존 설정 확인[5] kubeadm 설치 전 사전작업▶ 방화벽 해제 확인▶ 스왑(swap) 비활성화 확인(Swap에 할당된 자원이 없어야 함)(# 표시로 주석 처리가 잘 됐는지)[6] 컨테이너 런타임 설치[6-1] 컨테이너 런타임 설치 전 사전작업▶ 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 활성화 설정 확인▶ kubelet cgroup 확인 (configmap)▶ kubelet cgroup 확인 (kubelet)[7] kubeadm 설치▶ repo 설정 확인▶ 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 설치 확인

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

강의 수강학습 내용 요약그림으로 쉽게 배우는 운영체제 강의 - 완강그림으로 쉽게 배우는 자료구조와 알고리즘 - 완강학습 내용 회고후반부로 갈 수록 모르던 내용이 많아서 이해하기 위해 노력했다.동적 프로그래밍이나 알고리즘은 꾸준히 복습이 필요할 것 같다.미션해결 과정 요약미션 질문을 읽고, 바로 떠오르지 않는 내용은 강의를 다시 보며 복습하고 정리하여 작성했다.정답이 어느 정도 정해져 있더라도 조금 더 내 생각을 곱씹어 보며 미션을 수행했다.미션 해결 회고원리는 이해했는데 용어가 잘 안 외워지고 설명이 어려워서 조금 더 연습이 필요할 것 같다.개념을 정리하는 데에 조금 더 집중했던 것 같다.