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

6. ArgoCD Github 업데이트https://cafe.naver.com/kubeops/5531-3. 자동 배포 확인 - ArgoCD 상태 및 Dashboard Pod 생성 유무 : 에러 발생... Jenkins에 Github Token 등록 : 위치 바뀜https://github.com/settings/tokensghp_... https://github.com/chano275/kubernetes-anotherclass-sprint2/blob/main/2232-build-push-git/Jenkinsfile스테이징에 문제는 없었지만 argocd 하면서 계속 오류 발생... 아마 위에서 발생한 오류가 계속 영향을 끼친듯... 미션은 우선 제출하지만 발생한 오류는 다시 한번 더 복습하면서 해결해보도록 하겠습니다...! 아예 처음부터 다시 실습해보면서 클러스터 구성부터 kubectl 사용 / 젠킨스 / helm / argocd까지 직접 정리하며 구현해보겠습니다. 2번째 보는 강의지만 이번엔 특히 잘 배웠습니다 강사님...!

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

- 강의 수강 & 회고이번 주에는 ArgoCD 빠르게 레벨업강의를 수강했다. 드디어 마지막! 저번주 helm 커스터마이즈를 마무리하고 argocd를 들으면서 갈길이 멀다고 느끼면서도 이렇게 하나하나 알아가는 기분이 굉장히 뿌듯했다... 하지만 갈길은 멀다! (?)- 미션 요약한주차 밀린거 저번주에 잘 마무리 해서, 화요일 내로 마지막 미션 끝내고 완주해보도록 하겠습니다! 화이팅! 복습을 타 강의나 개인공부보다 조금 더 자세히 해서 이런 발자국이나 미션에 힘이 조금 빠지는감도 없지않아 있는거같네요 ㅋ큐ㅠ.... 하지만 자주 말 남기는거 같지만 강의 너무 만족스럽습니다. 강사님 감사해요!

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

Docker와 Containerd 명령 실습 :https://cafe.naver.com/kubeops/137 [root@cicd-server ~]# mkdir test [root@cicd-server ~]# ls anaconda-ks.cfg gradle-7.6.1-bin.zip original-ks.cfg test [root@cicd-server ~]# cd test [root@cicd-server test]# ls [root@cicd-server test]# curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/etc/docker/Dockerfile % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 60 100 60 0 0 155 0 --:--:-- --:--:-- --:--:-- 155 [root@cicd-server test]# curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/etc/docker/hello.js % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 178 100 178 0 0 497 0 --:--:-- --:--:-- --:--:-- 497 [root@cicd-server test]# ls Dockerfile hello.js 도커 허브 username : chano01794### 빌드 [root@cicd-server test]# docker build -t chano01794/hello:1.0.0 . [+] Building 22.1s (7/7) FINISHED docker:default => [internal] load .dockerignore 0.2s => => transferring context: 2B 0.0s => [internal] load build definition from Dockerfile 0.2s => => transferring dockerfile: 157B 0.1s => [internal] load metadata for docker.io/library/node:slim 2.7s => [internal] load build context 0.1s => => transferring context: 275B 0.1s => [1/2] FROM docker.io/library/node:slim@sha256:b30c143a092c7dced8e17ad67a8783c03234d4844ee84c39090c9780491aaf89 17.6s => => resolve docker.io/library/node:slim@sha256:b30c143a092c7dced8e17ad67a8783c03234d4844ee84c39090c9780491aaf89 0.1s => => sha256:26c0b956ed16dae9780bcb6c24f8161b3f8d44339c435691372d8fe1f270d97b 6.57kB / 6.57kB 0.0s => => sha256:dad67da3f26bce15939543965e09c4059533b025f707aad72ed3d3f3a09c66f8 28.23MB / 28.23MB 2.1s => => sha256:b30c143a092c7dced8e17ad67a8783c03234d4844ee84c39090c9780491aaf89 5.20kB / 5.20kB 0.0s => => sha256:1a6a7b2e2e2c80a6973f57aa8b0c6ad67a961ddbc5ef326c448e133f93564ff9 1.93kB / 1.93kB 0.0s => => sha256:ea9602600a53af802a015c3d6bc5298ce2b6dff888a6f93b2861465f710804c2 3.31kB / 3.31kB 0.8s => => sha256:e03b89ff903664199350b286d7985167de4c079a4ed44baefc09cc1d2e0395ca 51.04MB / 51.04MB 3.7s => => sha256:b03d7a90d937df6cc4c0c2e094b722156a78951c3b5cbe9c383f9a735ea3c316 1.71MB / 1.71MB 1.5s => => sha256:748509dbfbee9fa52f4b018cdaefbc837ee275e458fbdd76b96b312b764a27ac 447B / 447B 2.2s => => extracting sha256:dad67da3f26bce15939543965e09c4059533b025f707aad72ed3d3f3a09c66f8 9.0s => => extracting sha256:ea9602600a53af802a015c3d6bc5298ce2b6dff888a6f93b2861465f710804c2 0.0s => => extracting sha256:e03b89ff903664199350b286d7985167de4c079a4ed44baefc09cc1d2e0395ca 3.2s => => extracting sha256:b03d7a90d937df6cc4c0c2e094b722156a78951c3b5cbe9c383f9a735ea3c316 0.3s => => extracting sha256:748509dbfbee9fa52f4b018cdaefbc837ee275e458fbdd76b96b312b764a27ac 0.0s => [2/2] COPY hello.js . 1.0s => exporting to image 0.2s => => exporting layers 0.1s => => writing image sha256:5965305dbb8602727958bac3dd598f0a55551d0e595c002dad0d07b58c1bdb49 0.0s => => naming to docker.io/chano01794/hello:1.0.0 0.0s ### 이미지 리스트 조회 [root@cicd-server test]# docker image list REPOSITORY TAG IMAGE ID CREATED SIZE chano01794/hello 1.0.0 5965305dbb86 21 seconds ago 230MB chano01794/api-tester v1.0.0 529e022f4e15 2 hours ago 490MB ### 태그 변경 [root@cicd-server test]# docker tag chano01794/hello:1.0.0 chano01794/hello:2.0.0 [root@cicd-server test]# docker image list REPOSITORY TAG IMAGE ID CREATED SIZE chano01794/hello 1.0.0 5965305dbb86 45 seconds ago 230MB chano01794/hello 2.0.0 5965305dbb86 45 seconds ago 230MB chano01794/api-tester v1.0.0 529e022f4e15 2 hours ago 490MB ### 로그인 [root@cicd-server test]# docker login -u chano01794 Password: WARNING! Your password will be stored unencrypted in /root/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded ### 이미지 업로드 [root@cicd-server test]# docker push chano01794/hello:1.0.0 The push refers to repository [docker.io/chano01794/hello] 98ca109d077d: Pushed 8a45580a6679: Mounted from library/node d5b49e0b6f8f: Mounted from library/node eaf814c4be3d: Mounted from library/node 59cd39de7802: Mounted from library/node 7fb72a7d1a8e: Mounted from library/node ### 이미지 삭제 [root@cicd-server test]# docker rmi chano01794/hello:1.0.0 Untagged: chano01794/hello:1.0.0 [root@cicd-server test]# docker rmi chano01794/hello:2.0.0 Untagged: chano01794/hello:2.0.0 Untagged: chano01794/hello@sha256:7aa9b5ce123a7edc1cbebcd0b85360b3a2b38c8cc71a0ee43036673136858332 Deleted: sha256:5965305dbb8602727958bac3dd598f0a55551d0e595c002dad0d07b58c1bdb49 ### 이미지 다운로드 [root@cicd-server test]# docker pull chano01794/hello:1.0.0 1.0.0: Pulling from chano01794/hello dad67da3f26b: Already exists ea9602600a53: Already exists e03b89ff9036: Already exists b03d7a90d937: Already exists 748509dbfbee: Already exists 88b642bb1537: Already exists Digest: sha256:7aa9b5ce123a7edc1cbebcd0b85360b3a2b38c8cc71a0ee43036673136858332 Status: Downloaded newer image for chano01794/hello:1.0.0 docker.io/chano01794/hello:1.0.0 ### 이미지 -> 파일로 변환 [root@cicd-server test]# docker save -o file.tar chano01794/hello:1.0.0 [root@cicd-server test]# ls file.tar file.tar [root@cicd-server test]# ls Dockerfile file.tar hello.js ### 파일 -> 이미지로 변환 [root@cicd-server test]# docker load -i file.tar Loaded image: chano01794/hello:1.0.0 [root@cicd-server test]# docker image list REPOSITORY TAG IMAGE ID CREATED SIZE chano01794/hello 1.0.0 5965305dbb86 3 minutes ago 230MB chano01794/api-tester v1.0.0 529e022f4e15 2 hours ago 490MB ### 정리 [root@cicd-server test]# docker rmi chano01794/hello:1.0.0 Untagged: chano01794/hello:1.0.0 Untagged: chano01794/hello@sha256:7aa9b5ce123a7edc1cbebcd0b85360b3a2b38c8cc71a0ee43036673136858332 Deleted: sha256:5965305dbb8602727958bac3dd598f0a55551d0e595c002dad0d07b58c1bdb49 [root@cicd-server test]# [root@cicd-server test]# docker image list REPOSITORY TAG IMAGE ID CREATED SIZE chano01794/api-tester v1.0.0 529e022f4e15 2 hours ago 490MB 컨테이너디 ### 네임스페이스 조회 [root@k8s-master ~]# ctr ns list NAME LABELS k8s.io ### 특정 네임스페이스 내 이미지 조회 ctr -n k8s.io image list # 너무 많이 나오는데..? ### 다운로드 및 이미지 확인 (이미지는 default라는 네임스페이스에 다운 받아집니다.) [root@k8s-master ~]# ctr images pull docker.io/chano01794/hello:1.0.0 docker.io/chano01794/hello:1.0.0: resolved |++++++++++++++++++++++++++++++++++++++| manifest-sha256:7aa9b5ce123a7edc1cbebcd0b85360b3a2b38c8cc71a0ee43036673136858332: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:88b642bb153727bb4c187997177696815efcd9d0a0fe0b5757bc2f9c6cad1a3f: done |++++++++++++++++++++++++++++++++++++++| config-sha256:5965305dbb8602727958bac3dd598f0a55551d0e595c002dad0d07b58c1bdb49: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:dad67da3f26bce15939543965e09c4059533b025f707aad72ed3d3f3a09c66f8: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:ea9602600a53af802a015c3d6bc5298ce2b6dff888a6f93b2861465f710804c2: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:e03b89ff903664199350b286d7985167de4c079a4ed44baefc09cc1d2e0395ca: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:b03d7a90d937df6cc4c0c2e094b722156a78951c3b5cbe9c383f9a735ea3c316: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:748509dbfbee9fa52f4b018cdaefbc837ee275e458fbdd76b96b312b764a27ac: done |++++++++++++++++++++++++++++++++++++++| elapsed: 8.0 s total: 77.2 M (9.7 MiB/s) unpacking linux/amd64 sha256:7aa9b5ce123a7edc1cbebcd0b85360b3a2b38c8cc71a0ee43036673136858332... done: 7.472278898s [root@k8s-master ~]# ctr ns list NAME LABELS default k8s.io [root@k8s-master ~]# ctr images list REF TYPE DIGEST SIZE PLATFORMS LABELS docker.io/chano01794/hello:1.0.0 application/vnd.docker.distribution.manifest.v2+json sha256:7aa9b5ce123a7edc1cbebcd0b85360b3a2b38c8cc71a0ee43036673136858332 77.2 MiB linux/amd64 - ### 태그 변경 [root@k8s-master ~]# ctr images tag docker.io/chano01794/hello:1.0.0 docker.io/chano01794/hello:2.0.0 docker.io/chano01794/hello:2.0.0 [root@k8s-master ~]# ctr images list REF TYPE DIGEST SIZE PLATFORMS LABELS docker.io/chano01794/hello:1.0.0 application/vnd.docker.distribution.manifest.v2+json sha256:7aa9b5ce123a7edc1cbebcd0b85360b3a2b38c8cc71a0ee43036673136858332 77.2 MiB linux/amd64 - docker.io/chano01794/hello:2.0.0 application/vnd.docker.distribution.manifest.v2+json sha256:7aa9b5ce123a7edc1cbebcd0b85360b3a2b38c8cc71a0ee43036673136858332 77.2 MiB linux/amd64 - ### 업로드 [root@k8s-master ~]# ctr image push docker.io/chano01794/hello:2.0.0 --user chano01794 Password: manifest-sha256:7aa9b5ce123a7edc1cbebcd0b85360b3a2b38c8cc71a0ee43036673136858332: done |++++++++++++++++++++++++++++++++++++++| config-sha256:5965305dbb8602727958bac3dd598f0a55551d0e595c002dad0d07b58c1bdb49: done |++++++++++++++++++++++++++++++++++++++| elapsed: 3.1 s total: 8.9 Ki (2.9 KiB/s) ### 이미지 (namespace : default) -> 파일로 변환 [root@k8s-master ~]# ctr -n default image export file.tar docker.io/chano01794/hello:1.0.0 [root@k8s-master ~]# ls anaconda-ks.cfg file.tar k8s-local-volume monitoring original-ks.cfg ### 파일 -> 이미지로 변환 (namespace : k8s.io) [root@k8s-master ~]# ctr -n k8s.io image import file.tar unpacking docker.io/chano01794/hello:1.0.0 (sha256:7aa9b5ce123a7edc1cbebcd0b85360b3a2b38c8cc71a0ee43036673136858332)...done [root@k8s-master ~]# ctr -n k8s.io image list | grep hello docker.io/chano01794/hello:1.0.0 application/vnd.docker.distribution.manifest.v2+json sha256:7aa9b5ce123a7edc1cbebcd0b85360b3a2b38c8cc71a0ee43036673136858332 77.2 MiB linux/amd64 io.cri-containerd.image=managed ### 삭제 (namespace : k8s.io) [root@k8s-master ~]# ctr -n k8s.io image remove docker.io/chano01794/hello:1.0.0 docker.io/chano01794/hello:1.0.0 [root@k8s-master ~]# ctr -n k8s.io image list | grep hello Docker 이미지 사이즈 :https://cafe.naver.com/kubeops/158 ### [미션5] Docker vs Containerd 이미지 사이즈 차이 비교 실습 ### [STEP 1] Docker로 이미지 다운로드 및 사이즈 확인 (cicd-server에서 실행) # 목적: Docker가 실제 어떤 이미지 크기를 보여주는지 확인 [root@cicd-server test2]# docker pull 1pro/api-tester:latest latest: Pulling from 1pro/api-tester 38a980f2cc8a: Already exists de849f1cfbe6: Already exists a7203ca35e75: Already exists f3eeefdc54d7: Pull complete 4f4fb700ef54: Pull complete Digest: sha256:189625384d2f2856399f77b6212b6cfc503931e8b325fc1388e23c8a69f3f221 Status: Downloaded newer image for 1pro/api-tester:latest docker.io/1pro/api-tester:latest [root@cicd-server test2]# [root@cicd-server test2]# docker image list REPOSITORY TAG IMAGE ID CREATED SIZE 1pro/api-tester latest 08a0bfca3fbb 19 months ago 490MB # SIZE 약 490MB ### [STEP 2] Containerd로 이미지 다운로드 및 사이즈 확인 (k8s-master에서 실행) # 목적: Containerd는 동일한 이미지를 몇 MB로 보여주는지 확인 [root@k8s-master test2]# ctr image pull docker.io/1pro/api-tester:latest docker.io/1pro/api-tester:latest: resolved |++++++++++++++++++++++++++++++++++++++| index-sha256:189625384d2f2856399f77b6212b6cfc503931e8b325fc1388e23c8a69f3f221: done |++++++++++++++++++++++++++++++++++++++| manifest-sha256:da882e44367891d885b4557726ea8ffa1a6eaa8fe03ce85e1fb55a19dbf55978: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1: done |++++++++++++++++++++++++++++++++++++++| config-sha256:08a0bfca3fbb866e63ea5b601d44877ff76fbe3b054b4e0af06494501d5b0eb3: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:38a980f2cc8accf69c23deae6743d42a87eb34a54f02396f3fcfd7c2d06e2c5b: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:de849f1cfbe60b1c06a1db83a3129ab0ea397c4852b98e3e4300b12ee57ba111: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:a7203ca35e75e068651c9907d659adc721dba823441b78639fde66fc988f042f: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:f3eeefdc54d7d01fa080d4edf5f1ddd080b446a1633ed1b619faff8159f4b083: done |++++++++++++++++++++++++++++++++++++++| elapsed: 3.7 s total: 2.8 Ki (771.0 B/s) unpacking linux/amd64 sha256:189625384d2f2856399f77b6212b6cfc503931e8b325fc1388e23c8a69f3f221... done: 12.67536041s [root@k8s-master test2]# ctr image list | grep api-tester docker.io/1pro/api-tester:latest application/vnd.oci.image.index.v1+json sha256:189625384d2f2856399f77b6212b6cfc503931e8b325fc1388e23c8a69f3f221 248.3 MiB linux/amd64,linux/arm64,unknown/unknown - # SIZE 약 248.3 MiB ### [STEP 3] Docker 이미지 저장 → 파일 (cicd-server에서 실행) # 목적: 동일한 이미지를 파일로 저장했을 때 사이즈 확인 [root@cicd-server test2]# docker save -o docker-image.tar 1pro/api-tester:latest [root@cicd-server test2]# ls -lh docker-image.tar -rw-------. 1 root root 472M Jun 17 16:50 docker-image.tar # -> 약 472MB ### [STEP 4] 파일 전송 → 배포 서버로 (cicd-server에서 실행) [root@cicd-server test2]# scp docker-image.tar root@192.168.56.30:/root root@192.168.56.30's password: docker-image.tar 100% 472MB 34.0MB/s 00:13 ### [STEP 5] Containerd에서 기존 이미지 삭제 후 import (k8s-master에서 실행) # 목적: Docker에서 만든 tar 파일을 Containerd로 import 해보며 사이즈 변화 체크 [root@k8s-master test2]# ctr image rm docker.io/1pro/api-tester:latest docker.io/1pro/api-tester:latest [root@k8s-master test2]# cd .. [root@k8s-master ~]# ls anaconda-ks.cfg docker-image.tar file.tar k8s-local-volume monitoring original-ks.cfg test2 [root@k8s-master ~]# ctr image import docker-image.tar unpacking docker.io/1pro/api-tester:latest (sha256:ce5b6c9e3b93096e8813c99528af58fd2603bb7e46e8023f131acab303e55836)...done [root@k8s-master ~]# ctr image list | grep api-tester docker.io/1pro/api-tester:latest application/vnd.docker.distribution.manifest.v2+json sha256:ce5b6c9e3b93096e8813c99528af58fd2603bb7e46e8023f131acab303e55836 471.5 MiB linux/amd64 - # -> 결과: 약 471.5 MiB # ** scp 로 ~에 보내서 기존에 다른 폴더 만든데랑 꼬여서 중간에 cd.. 넣었... ### [STEP 6] Containerd에서 다시 다운로드 후 파일로 저장 (k8s-master에서 실행) # 목적: Containerd가 다운로드한 이미지를 파일로 export 해보고 크기 비교 [root@k8s-master ~]# ctr image rm docker.io/1pro/api-tester:latest docker.io/1pro/api-tester:latest [root@k8s-master ~]# ctr image pull docker.io/1pro/api-tester:latest docker.io/1pro/api-tester:latest: resolved |++++++++++++++++++++++++++++++++++++++| index-sha256:189625384d2f2856399f77b6212b6cfc503931e8b325fc1388e23c8a69f3f221: done |++++++++++++++++++++++++++++++++++++++| manifest-sha256:da882e44367891d885b4557726ea8ffa1a6eaa8fe03ce85e1fb55a19dbf55978: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1: done |++++++++++++++++++++++++++++++++++++++| config-sha256:08a0bfca3fbb866e63ea5b601d44877ff76fbe3b054b4e0af06494501d5b0eb3: exists |++++++++++++++++++++++++++++++++++++++| layer-sha256:38a980f2cc8accf69c23deae6743d42a87eb34a54f02396f3fcfd7c2d06e2c5b: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:de849f1cfbe60b1c06a1db83a3129ab0ea397c4852b98e3e4300b12ee57ba111: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:a7203ca35e75e068651c9907d659adc721dba823441b78639fde66fc988f042f: done |++++++++++++++++++++++++++++++++++++++| layer-sha256:f3eeefdc54d7d01fa080d4edf5f1ddd080b446a1633ed1b619faff8159f4b083: done |++++++++++++++++++++++++++++++++++++++| elapsed: 3.7 s total: 2.8 Ki (772.0 B/s) unpacking linux/amd64 sha256:189625384d2f2856399f77b6212b6cfc503931e8b325fc1388e23c8a69f3f221... done: 25.828317ms [root@k8s-master ~]# ctr image export containerd-image.tar docker.io/1pro/api-tester:latest [root@k8s-master ~]# ls -lh containerd-image.tar -rw-r--r--. 1 root root 249M Jun 17 17:02 containerd-image.tar # -> 약 249MB ### [STEP 7] 파일 전송 → Docker 서버로 복사 (k8s-master에서 실행) [root@k8s-master ~]# scp containerd-image.tar root@192.168.56.20:/root The authenticity of host '192.168.56.20 (192.168.56.20)' can't be established. ECDSA key fingerprint is SHA256:l/1SJtioqx5vZeMC7uILw/KtalAXEavCzYllT7ZWmuo. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.56.20' (ECDSA) to the list of known hosts. root@192.168.56.20's password: containerd-image.tar 100% 248MB 38.0MB/s 00:06 ### [STEP 8] Docker에서 기존 이미지 삭제 후 containerd 이미지 import (cicd-server에서 실행) [root@cicd-server test2]# ls docker-image.tar [root@cicd-server test2]# docker image rm 1pro/api-tester:latest Untagged: 1pro/api-tester:latest Untagged: 1pro/api-tester@sha256:189625384d2f2856399f77b6212b6cfc503931e8b325fc1388e23c8a69f3f221 Deleted: sha256:08a0bfca3fbb866e63ea5b601d44877ff76fbe3b054b4e0af06494501d5b0eb3 Deleted: sha256:e2fb66ac6dafbd5edcc5d3ff932de5fad633224097fe643b49c04dd9d56193d6 Deleted: sha256:2029a1bf55bf9a369aa169dfc17ecd7da632987259d1c8c303778b24db5f8bbd [root@cicd-server test2]# cd .. [root@cicd-server ~]# ls anaconda-ks.cfg containerd-image.tar gradle-7.6.1-bin.zip original-ks.cfg test test2 [root@cicd-server ~]# docker load -i containerd-image.tar b54d2aff45ec: Loading layer [==================================================>] 17.15MB/17.15MB 5f70bf18a086: Loading layer [==================================================>] 32B/32B Loaded image: 1pro/api-tester:latest [root@cicd-server ~]# docker image list REPOSITORY TAG IMAGE ID CREATED SIZE chano01794/api-tester v1.0.0 529e022f4e15 4 hours ago 490MB 1pro/api-tester latest 08a0bfca3fbb 19 months ago 490MB # -> 결과: 다시 490MB로 증가

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

- 강의 수강 & 회고 이번 주에는 데브옵스 한방 정리 / 손쉽게 데브옵스 환경을 구축하는 방법 / 배포를 시작하기 전에 반드시 알아야 할 것들 / Jenkins Pipeline (기초부터 Blue/Green 까지) / Helm과 Kustomize 비교하며 사용강의를 수강했다. 기존 프로젝트를 진행하며 큰그림을 못보고, 필요한것을 하나하나 했다는 느낌이 컸는데 이번 강의를 보면서 기존에 했던걸 재확인하고 이런 방식으로 하면 더 좋겠구나 ( 특히 젠킨스 ) 생각을 하게 되었고, 사용해보지 못했던 기술에 대해서 알고, 사용해보며 데브옵스적 방향성을 조금 더 잡을 수 있었다? 너무 만족스러웠다. 개인적으로 첫번째 강의가 가장 만족스러웠다! - 미션 요약저번주차 미션이 하나 밀려서, 빠르게 해결했고 이번주 미션을 오늘부터 해서 해보려 한다. 아마 프로젝트 때에 자주 했던 거라서 ( 환경만 다르니 ) 빠르게 마무리해서 화요일까지 업로드 예정...! 화이팅 하겠습니다.

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

실습자료실의 파일 생성 api 2개 > 각각의 폴더에 파일만들어짐 > 3군데 위치에서 파일 생성된걸 확인 > Pod 삭제 > 저 위치에서 다시 파일 확인hostPath 써서 똑같이 실행 로컬 동작 확인 [root@k8s-master ~]# kubectl get pods -n anotherclass-123 NAME READY STATUS RESTARTS AGE api-tester-1231-6fd678cd55-gbjtx 1/1 Running 0 11m api-tester-1231-6fd678cd55-hprxx 1/1 Running 0 110s // 1번 API - 파일 생성 curl http://192.168.56.30:31231/create-file-pod curl http://192.168.56.30:31231/create-file-pv [root@k8s-master ~]# curl http://192.168.56.30:31231/create-file-pod abmfbdhohw.txt [root@k8s-master ~]# curl http://192.168.56.30:31231/create-file-pv tjvoyjqsql.txt jawhiikqtb.txt helfolpopo.txt 에러때문에 3번 진행했다가 3개 생성... 아니 그냥 이거를 했을 때에 무조건 replicas 를 1로 바꾸나..? [root@k8s-master ~]# kubectl get pods -n anotherclass-123 NAME READY STATUS RESTARTS AGE api-tester-1231-6fd678cd55-gbjtx 1/1 Running 0 16m api-tester-1231-6fd678cd55-gbjtx // 2번 - Container 임시 폴더 확인 kubectl exec -n anotherclass-123 -it api-tester-1231-6fd678cd55-gbjtx -- ls /usr/src/myapp/tmp // 2번 - Container 영구저장 폴더 확인 kubectl exec -n anotherclass-123 -it api-tester-1231-6fd678cd55-gbjtx -- ls /usr/src/myapp/files/dev // 2번 - master node 폴더 확인 ls /root/k8s-local-volume/1231 [root@k8s-master ~]# kubectl exec -n anotherclass-123 -it api-tester-1231-6fd678cd55-gbjtx -- ls /usr/src/myapp/tmp abmfbdhohw.txt [root@k8s-master ~]# kubectl exec -n anotherclass-123 -it api-tester-1231-6fd678cd55-gbjtx -- ls /usr/src/myapp/files/dev helfolpopo.txt jawhiikqtb.txt tjvoyjqsql.txt [root@k8s-master ~]# ls /root/k8s-local-volume/1231 helfolpopo.txt jawhiikqtb.txt tjvoyjqsql.txt [root@k8s-master ~]# kubectl delete -n anotherclass-123 pod api-tester-1231-6fd678cd55-gbjtx pod "api-tester-1231-6fd678cd55-gbjtx" deleted [root@k8s-master ~]# curl http://192.168.56.30:31231/list-file-pod [root@k8s-master ~]# curl http://192.168.56.30:31231/list-file-pv tjvoyjqsql.txt jawhiikqtb.txt helfolpopo.txt POD에 생성한 파일은 날아가고, PV 받아 생성한 파일은 남아있음 ( 오류 2번 있었어서, 파일 총 3개인 모습 ) 2. hostPath 동작 확인 spec: volumes: - name: files hostPath: path: /root/k8s-local-volume/1231 deployment 수정 [root@k8s-master ~]# kubectl get pods -n anotherclass-123 NAME READY STATUS RESTARTS AGE api-tester-1231-7998bc7d89-7pqlr 1/1 Running 0 84s 완료. 위와 동일한 동작! [root@k8s-master ~]# curl http://192.168.56.30:31231/create-file-pod yhwyoujvgo.txt [root@k8s-master ~]# curl http://192.168.56.30:31231/create-file-pv ygvvkrwlzq.txt tjvoyjqsql.txt jawhiikqtb.txt helfolpopo.txt [root@k8s-master ~]# kubectl exec -n anotherclass-123 -it api-tester-1231-7998bc7d89-7pqlr -- ls /usr/src/myapp/tmp yhwyoujvgo.txt [root@k8s-master ~]# kubectl exec -n anotherclass-123 -it api-tester-1231-7998bc7d89-7pqlr -- ls /usr/src/myapp/files/dev helfolpopo.txt jawhiikqtb.txt tjvoyjqsql.txt ygvvkrwlzq.txt [root@k8s-master ~]# ls /root/k8s-local-volume/1231 helfolpopo.txt jawhiikqtb.txt tjvoyjqsql.txt ygvvkrwlzq.txt [root@k8s-master ~]# curl http://192.168.56.30:31231/list-file-pod [root@k8s-master ~]# curl http://192.168.56.30:31231/list-file-pv ygvvkrwlzq.txt tjvoyjqsql.txt jawhiikqtb.txt helfolpopo.txt 실습 :Rollingupdate# 1) HPA minReplica 2로 바꾸기 (이전 강의에서 minReplicas를 1로 바꿔놨었음) [root@k8s-master ~]# kubectl patch -n anotherclass-123 hpa api-tester-1231-default -p '{"spec":{"minReplicas":2}}' horizontalpodautoscaler.autoscaling/api-tester-1231-default patched # 1) 그외 Deployment scale 명령 [root@k8s-master ~]# kubectl scale -n anotherclass-123 deployment api-tester-1231 --replicas=2 deployment.apps/api-tester-1231 scaled # 1) edit 모드로 직접 수정 kubectl edit -n anotherclass-123 deployment api-tester-1231 # 2) 지속적으로 Version 호출하기 (RollingUpdate 중 리턴값 관찰) while true; do curl http://192.168.56.30:31231/version; sleep 2; echo ''; done; # 3) 별도의 원격 콘솔창에서 업데이트 실행 [root@k8s-master ~]# kubectl set image -n anotherclass-123 deployment/api-tester-1231 api-tester-1231=1pro/api-tester:v2.0.0 deployment.apps/api-tester-1231 image updated [App Version] : Api Tester v1.0.0 [App Version] : Api Tester v1.0.0 [App Version] : Api Tester v1.0.0 [App Version] : Api Tester v2.0.0 [App Version] : Api Tester v1.0.0 [App Version] : Api Tester v2.0.0 [App Version] : Api Tester v1.0.0 [App Version] : Api Tester v1.0.0 [App Version] : Api Tester v2.0.0 [App Version] : Api Tester v1.0.0 [App Version] : Api Tester v2.0.0 [App Version] : Api Tester v1.0.0 [App Version] : Api Tester v2.0.0 [App Version] : Api Tester v2.0.0 [App Version] : Api Tester v2.0.0 [App Version] : Api Tester v2.0.0 # (현재 이미지 상태 확인) kubectl set image -n anotherclass-123 deployment/api-tester-1231 # [참고] 업데이트 실행 명령 포맷: # kubectl set image -n deployment/ =: 0% / 100% :deployment 수정 & 확인 rollingUpdate: maxUnavailable: 25% -> 0% # 수정 maxSurge: 25% -> 100% # 수정 [root@k8s-master ~]# kubectl set image -n anotherclass-123 deployment/api-tester-1231 api-tester-1231=1pro/api-tester:v1.0.0 deployment.apps/api-tester-1231 image updated # 블루그린 느낌 내게. 부하 2배 걸리지만 무중단 Recreate : deployment 수정 & 확인 spec: replicas: 2 strategy: type: RollingUpdate -> Recreate # 수정 rollingUpdate: # 삭제 maxUnavailable: 0% # 삭제 maxSurge: 100% # 삭제 [root@k8s-master ~]# kubectl set image -n anotherclass-123 deployment/api-tester-1231 api-tester-1231=1pro/api-tester:v2.0.0 deployment.apps/api-tester-1231 image updated # 0~2개로 유지 > 다운타임 생김 Rollback [root@k8s-master ~]# kubectl rollout undo -n anotherclass-123 deployment/api-tester-1231 deployment.apps/api-tester-1231 rolled back [root@k8s-master ~]# kubectl get deployment api-tester-1231 -n anotherclass-123 -o yaml | grep -A5 strategy strategy: type: Recreate template: metadata: creationTimestamp: null labels: # 아예 rolling update로 돌아가는건 아니구만... 정확히는 잘 모르겠다 실습서비스 디스커버리 ( 별도 Pod 생성 X, 파드 내부에서 API 날려보기 )// Version API 호출 curl http://api-tester-1231:80/version APP 내부의 ports 삭제 > service 도 http 대신 8080 변경하고 API 날리기 > 성공하는지 (*containerPort는 정보성 역할이라 되어야 함 *) # Deployment에서 Pod의 ports 전체 삭제 containers: - name: api-tester-1231 ports: // 삭제 - name: http // 삭제 containerPort: 8080 // 삭제 --- # Service targetPort를 http -> 8080으로 수정 spec: ports: - port: 80 targetPort: http -> 8080 // 변경 nodePort: 31231 type: NodePort # 그리고 다시 Pod 내부에서 Service 명으로 API 호출 bash-4.4# curl http://api-tester-1231:80/version [App Version] : Api Tester v1.0.0 실습behavior 기능 적용되어있는 상태 > 2분 이상 부하 발생해야 scale out# 3분동안 부하 발생 ( * Pod에 부하가 심할 경우 livenessProbe에 의해 파드가 restart 가능 ) curl http://192.168.56.30:31231/cpu-load?min=3 # 개인 PC 사양(core 수)에 따라 부하가 너무 오르거나/오르지 않을 경우 queryparam으로 수치 조정 curl http://192.168.56.30:31231/cpu-load?min=3&thread=5 # 3분 동안 5개의 쓰레드로 80% 부하 발생 ( default : min=2, thread=10 ) # 부하 확인 - 실시간 업데이트는 명령어로 확인하는 게 빨라요 # HPA 상태 확인 kubectl get hpa -n anotherclass-123 # 리소스 모니터링 kubectl top -n anotherclass-123 pods ### [root@k8s-master ~]# kubectl get hpa -n anotherclass-123 NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE api-tester-1231-default Deployment/api-tester-1231 5%/60% 2 4 2 5d22h [root@k8s-master ~]# kubectl get hpa -n anotherclass-123 NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE api-tester-1231-default Deployment/api-tester-1231 29%/60% 2 4 2 5d22h [root@k8s-master ~]# kubectl get hpa -n anotherclass-123 NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE api-tester-1231-default Deployment/api-tester-1231 61%/60% 2 4 2 5d22h ### # Grafana는 Prometheus를 거쳐 오기 때문에 좀 늦습니다 Grafana > Home > Dashboards > [Default] Kubernetes / Compute Resources / Pod 확인이 쉽지 않다... 3분 계속 기다렸는데 2분동안 계속 60%보다 높아서 그런듯? 밑에거 시도해보기 scale up 설정 지우고 부하 > 기다리지 않고 스케일 아웃 # [behavior] 미사용으로 적용 # 그냥 nano 설치하고 그걸로 수정했음. 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 # 삭제 # 부하 발생 API curl http://192.168.56.30:31231/cpu-load // 2분 동안 10개의 쓰레드로 80% 부하 발생 // default : min=2, thread=10 # 부하 확인 (kubectl) # HPA 상태 확인 kubectl get hpa -n anotherclass-123 # 리소스 모니터링 kubectl top -n anotherclass-123 pods [root@k8s-master ~]# # HPA 상태 확인 [root@k8s-master ~]# kubectl get hpa -n anotherclass-123 NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE api-tester-1231-default Deployment/api-tester-1231 182%/60% 2 4 3 5d22h # 부하 확인 (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] 클릭# 부하 확인 (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.

저번에는 딱딱 적을게 있을 것 같았는데 app 확인이 살아있기만 하면 되는건지...?미션을 읽어도 잘 모르겠어서 일단 제출...! 나중에 다른사람들꺼보고 수정할 거 있다면 다시 하겠습니다. 응용1 : - Configmap의 환경변수들을 Secret을 사용해서 작성하고, App에서는 같은 결과가 나오도록 확인해 보세요.☞ Secret을 이렇게 사용하는 경우는 별로 보지 못했습니다. 여러가지 방법으로 Secret을 만들어본다는데 의의를 두시면 됩니다. 답두번째 실행이 첫번째꺼를 갱신세번째꺼는 그대로생성된 secret deployment 변경 전 / 후 응용2 : - 반대로 Secret의 DB정보를 Configmap으로 만들어보고 App을 동작시켜 보세요☞ Configmap을 Volume에 연결해서 쓰는 케이스는 매우 많습니다. 답 configmap 으로 바꾸고, deployment 업데이트 > app 잘 작동하여 살아있음.

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

응용 1startupProbe가 실패 되도록 설정해서 Pod가 무한 재기동 상태가 되도록 설정해 보세요. (여러분들이 가장 많이 겪게될 Pod 에러입니다) 답https://192.168.56.30:30000/#/deployment?namespace=anotherclass-123대시보드에서 내가 사용하고있던 네임스페이스의 deployment 에 가서 수정deployment 수정 이유? Pod를 수정한다고 해도 결국 deployment 의 yaml 파일에서 프로브 설정 적혀있으므로. failureThreshold 를 1로 하면 무조건 실패해서 Pod를 재기동 > 무한반복 아닐까? startupProbe: httpGet: path: /startup port: 8080 scheme: HTTP timeoutSeconds: 1 periodSeconds: 5 successThreshold: 10 failureThreshold: 1# 36이거로 해보니, 일단 #로 시작하는걸 저기 붙이면 안되는거 같고, successThreshold 는 무조건 1이어야 하는듯? 명시하지 않으면 자동으로 1로 동작한다고 해서, success와 failure 를 둘다 1로 명시해보고 try startupProbe: 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-off답 timeoutSeconds: 1 # 1초 안에 응답 없으면 실패로 간주 periodSeconds: 10 # 10초마다 헬스체크 successThreshold: 1 # 1번만 성공하면 성공으로 인정 > 이건 없어도 기본값 1이랬음 failureThreshold: 3 # 3번 연속 실패 시 컨테이너 재시작 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위에 api 날리면 둘다 동시에 멈춘다고 했음. 외부 트래픽 > readinessProbe, 앱 살아있는지 체크 > livenessProbe30초 후 트래픽 중단, 3분 뒤 app 재기동 이니, 위와 같이 10초씩 3번 실패하면 service pod 연결 해제1분씩 3번 실패하면 pod 재기동 기존에 밑에 정리한 대로, 하여 위와 같은 테스팅 > liveness 프로브 : APP 잘 살아있니? - 실패시 장애라고 판단하고 Pod 를 재기동 readiness 프로브 : 외부 트래픽 넣어도 괜찮니? - 성공 나오면 Service Pod 연결 - 중간에 실패 나오면 다시 연결 해제하고, 성공 뜨면 또다시 재연결3분 지나고 pod 재시동 ( 로그 확인 ) 30초 지나고 외부 api 꺼짐파드 다시 켜지고 Pod 들어가서 부하 줄이는 코드 > 외부에서 api 호출했을 때에 잘 반응>> 부하가 많이 걸릴 때에, Pod를 재기동하기 보다는 일단 외부 api 호출을 막아서 app의 부담을 덜고 >> 3분동안 처리했을 때에도 처리가 다 안되면 pod 재기동? 결국은 read 보다 live 를 많이 잡는게 좋을듯 응용 3Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요.(꼭 API를 날리는 것만이 readinessProbe 활용의 전부는 아닙니다)답exec은 readinessProbe, livenessProbe, startupProbe 모두에서 사용 가능. 해당 파드의 컨테이너 안에 해당 명령어가 있어야 하고, 프로브가 실행될 때 그 명령어가 컨테이너 안에서 직접 실행문제에서 readinessProbe 가 Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml) 존재 여부를 파악하라 했으므로 cat 명령어를 이용해 있는지, 있다면 내용 뱉으라 확인 readinessProbe: exec: command: ["cat", "/usr/src/myapp/datasource/postgresql-info.yaml"] periodSeconds: 10 failureThreshold: 3 ** 강사님 답 보고 알아낸 사실 ☞ HTTP 명령이 아니기 때문에 로그에서 Readiness probe가 찍히는건 볼 수 없습니다.☞ 하지만 command 명령에 실패(해당 파일이 없을 때)하면 아래와 같이 event로 실패 로그를 볼 수 있어요어쩐지 로그가 안찍히더라. 참고로, 위와 같이 그대로 코드 넣고 deployment 없데이트 했을 때 나중에 들어가보면 아래와 같이 바뀌어 있고, 주석도 사라짐 ( 주의 ) readinessProbe: exec: command: - cat - /usr/src/myapp/datasource/postgresql-info.yaml timeoutSeconds: 1 periodSeconds: 10 successThreshold: 1 failureThreshold: 3 근데 이렇게 했을떄에, 대시보드에서 exec 치고 cat 하면 되는데, 이벤트로 안뜬다. 왜? 내 생각에는, 기존에 liveness를 60초로 걸어두고 readiness 만 바꾸고 시작해서,,,? 음... 잘 모르겠다...

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

- 강의 수강이번 주에는 Application 기능으로 k8s 이해 - Probe / Configmap, Secret / PV/PVC, Deployment, Service, HPA, Component 동작으로 k8s 이해 강의를 수강했다. 이전주차에서 Object를 그려보며 쿠버네티스 이해 강의를 통해 전체적으로 봤던 내용들을 하나하나 뜯어보며 이해하는 시간을 가졌다. - 미션 요약이번 주에는 Probe 응용과제를 수행했다. startupProbe 실패로 인한 무한 재기동 상황을 재현하고, 일시적 부하로 인해 readinessProbe → livenessProbe 순으로 실패하며 재기동되는 흐름을 설정해보았다. 또한 특정 파일 존재 여부를 기준으로 readiness 상태를 판단하는 실습을 통해, Probe가 단순한 응답 체크를 넘어 실제 앱 조건에 맞게 다양하게 활용될 수 있다는 걸 확인할 수 있었다. 이번 주는 미션 2까지만 수행했고, Configmap/Secret 응용과제, PV/PVC, Deployment, HPA 실습과제와 미션 2에 대한 정리 조금 더 해서 화요일까지 올려보겠다... 화이팅 - 회고Object를 그려보며 쿠버네티스 이해 강의 자체도 너무 좋았는데, 이번 주에 그걸 조금 더 들어가면서 내가 프로젝트를 진행하면서 이해가 어려웠던 부분들, 헷갈렸던 구조들을 조금 더 정확히 배울 수 있어서 정말 만족스러웠다. 예전에는 그냥 외워서 넘겼던 오브젝트 간 관계나 흐름들이 이제는 머릿속에 그려지면서 전체 구조를 어떻게 설계해야 할지 감이 생기기 시작한 느낌이다. 다음 주에는 남은 실습들을 마무리하면서, 실제 프로젝트에 적용할 수 있을 만큼 더 확실히 다져둘 계획이다.

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

https://cafe.naver.com/kubeops/24https://cafe.naver.com/kubeops/28 [1-1] 내 PC 네트워크 확인 [1-2] 내 PC 자원 확인 [1-3] VirtualBox 설치 버전 확인 [1-4] Vagrant 설치 버전 확인[1-5] 원격접속(MobaXterm) 설치 버전 확인[2-1] VirtualBox VM 확인 [2-2] 내 VM에 적용된 네트워크 확인 [2-3] 내 VM에 적용된 Host-Only Network 확인[2-4] VirtualBox Host-Only cidr 확인 [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 설치 확인

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

- 강의 수강이번 주에는 컨테이너 한방 정리, 무게감 있게 쿠버네티스 설치, 실무에서 느껴 본 쿠버네티스 정말 편한 이유, Object를 그려보며 쿠버네티스 이해4가지 강의를 플젝중에 필요한 정보를 얻기 위해서 휙휙 들었던 것과 다르게 천천히 다시볼 수 있었다. 예전에는 서버가 준비되어 있는 환경에서만 작업해왔기 때문에, 강의를 처음 들을 때는 환경 세팅의 중요성을 크게 못 느꼈다. 하지만 이번 스터디를 통해 혼자 DevOps 환경을 직접 세팅해보면서 이런 환경 구축이 DevOps에게 얼마나 중요한지 새삼 깨닫게 되었다.- 미션 요약미션1은 쿠버네티스 실습을 위한 환경 세팅이었다.Vagrant와 VirtualBox를 이용해 로컬에서 가상 머신을 띄우고, 쿠버네티스 실습 환경을 만드는 작업이었다.처음에는 강의만으로 이해가 부족했지만, 이번에는 직접 명령어를 치고, 플러그인 설치, 박스 추가, 환경 실행까지 해보면서단순히 코드나 기능만 보는 것이 아니라 실제 DevOps 업무의 기반을 다지는 환경 세팅 경험이 중요하다는 걸 배웠다. ( 화요일까지 정리해서 올려야지 ... ) - 회고혼자 할 때는 몰랐던 부분들을 이번 스터디로 조금 더 꼼꼼하게 채워넣을 수 있었다.특히 앞으로는 프로젝트를 할 때도 환경 세팅을 소홀히 하지 않고, 더 꼼꼼히 챙겨야겠다고 느꼈다.다음 주에는 더 깊게 실습에 참여하고, 내가 약했던 부분을 채워가는 걸 목표로 하고 싶다.