인프런워밍업클럽4기 devops - [미션6] ArgoCD Github 업데이트

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//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 POLICY ​1-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 > Jenkinsfile def 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/Jenkinsfile 3-3.[저장] 후 [지금 빌드] 실행 (이때는 파라미터가 없어서 실행되지 않아요!)​3-4.[파라미터와 함께 빌드] 선택 후 본인의 DockerHub와 Github의 Username 입력 후 [빌드] 실행​3-5.Stage View결과 확인​3-6. ArgoCD에서 자동 배포 확인​3-7. 다시 빌드 후 재확인 출처https://cafe.naver.com/kubeops/553

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

[강의]#1.Helm과 Kustomize 비교하며 사용-2#2.ArgoCD 빠르게 레벨업-1#3.ArgoCD 빠르게 레벨업-2#4.ArgoCD 빠르게 레벨업-3 [미션 진행 소감]마지막 주차까지 끝났다. 처음 목표를 했던 다짐과 의지보다는 성실히 잘 수행하지는 못했던 것 같고 개념과 지식을 모두 학습하겠다는 목표도 지키지는 못했던 것 같다. 물론 첫술에 배부를순 없지만 그래도 하나 의미있게 생각할 수 있는건 수료를 했다는 것이다. 작은 성공 경험이 쌓여서 큰 성공 경험을 만들어낸다고 하는데 나는 이런 작은 성공 경험이 올해에 몇개씩은 쌓이고 있는 것 같아서 유의미하게 생각한다. 이런 워밍업클럽을 만들어준 인프런에게 감사하고 데브옵스4기를 진행해준 일프로 강사님에게 정말 고맙다는 이야기를 하고싶다. 강사님의 수업자료나 준비 자료들을 보면 매번 감탄이 나온다. 이제 내가 해야할건 복습과 조금 더 쿠버네티스에 친숙해지기이다. 난 SI 개발자인데 사실 인프라를 다루는게 크게 많지는 않다. 가끔 운영업무를 할 때가 있는데 그때 k8s를 처음 경험해봤다. 강의 마지막까지 들었을때 그때 운영사에서 쓴 ArgoCD 라던지 Jenkins에 대해서 조금은 이해할 수 있게되어서 좋았다. 이제는 그런 지식을 내 머릿속에 확실하게 그림과 개념으로 정리할때라고 본다. 비록 6월달에 이제 워밍업클럽 4기가 끝나지만... 강의는 항상 무제한으로 수강할 수 있으니 계속계속 듣고 정리하고 내 지식으로 남겨야겠다. 감사합니다.

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

[강의]#1.데브옵스 한방정리#2.손쉽게 데브옵스 환경을 구축하는 방법#3.배포를 시작하기 전에 반드시 알아야 할 것들#4.Jenkins Pipeline (기초부터 Blue/Green 까지)#5.Helm과 Kustomize 비교하며 사용하기 (1/2) [미션 진행 소감]어렵다..너무 어렵다.. 따라만 해도 되는게 신기하고 그만큼 강사님이 열심히 정리해주셨다는게 따라하면서도 느껴진다.그래도 이번 젠킨스랑 CI/CD쪽 강의를 들으면서 SM 운영업무를 했을때 이런식으로 구성을 했었겠구나 라는 조금의 가르침을 받게되었다.앞으로 해야 할일은 그냥 무한반복 하면서 계속 강의를 듣는수 밖에 없을 것 같다.

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

도커 (Docker) [쿠버네티스 어나더 클래스] 수강생 분들께서는 cicd-server에서 작업하시면 됩니다. ▶ 사전 준비사항# 도커 파일 및 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.js▶ 업로드 실습을 해보기 위해서는 본인의 도커 허브 Username 필요1. docker build -t tjdtjq91/hello:1.0.0 . 2. docker image list 3. docker tag tjdtjq91/hello:1.0.0 tjdtjq91/hello:2.0.0 4-1. docker login -u 1pro 4-2. docker push tjdtjq91/hello:1.0.0 5. docker rmi tjdtjq91/hello:1.0.0 6. docker pull tjdtjq91/hello:1.0.0 7. docker save -o file.tar tjdtjq91/hello:1.0.0 8. docker load -i file.tar​1. 빌드2. 이미지 리스트 조회3. 태그 변경4-1. 로그인4-2. 이미지 업로드5. 이미지 삭제6. 이미지 다운로드 7. 이미지 -> 파일로 변환▶ 이미지 삭제8. 파일 -> 이미지로 변환컨테이너디 (Containerd)[쿠버네티스 어나더 클래스] 수강생 분들께서는 k8s-master에서 작업하시면 됩니다.1. ctr ns list 2. ctr -n k8s.io image list 3. ctr images pull docker.io/tjdtjq91/hello:1.0.0 4. ctr images tag docker.io/tjdtjq91/hello:1.0.0 docker.io/tjdtjq91/hello:2.0.0 5. ctr image push docker.io/tjdtjq91/hello:2.0.0 --user 1pro 6. ctr -n default image export file.tar docker.io/tjdtjq91/hello:1.0.0 7. ctr -n k8s.io image import file.tar 8. ctr -n k8s.io image remove docker.io/tjdtjq91/hello:1.0.0​1. 네임스페이스 조회여기서 이미지에 대한 namespace의 개념은 중요합니다. 컨테이너 런타임으로 containerd를 쓰고 있는 쿠버네티스 입장에서 이 [k8s.io] 네임스페이스에 있는 이미지들을 사용하거든요.(사용자가 네임스페이스 지정없이 수동으로 이미지를 다운 받았다면 default라는 namespace에 이미지가 만들어지게 되고 그럴 경우 쿠버네티스에서 사용할 수 없게 됩니다)2. 특정 네임스페이스 내 이미지 조회3. 다운로드 및 이미지 확인 (이미지는 default라는 네임스페이스에 다운 받아집니다.)4. 태그 변경5. 업로드6. 이미지 (namespace : default) -> 파일로 변환7. 파일 -> 이미지로 변환 (namespace : k8s.io) 8. 삭제 (namespace : k8s.io)같은 이미지를 도커에서 받았을 때와 쿠버네티스에서 받았을 때 사이즈가 다른 이유먼저 Docker Hub에서 이미지 사이즈를 보겠습니다.▶ Docker Hub (248.26 MB)https://hub.docker.com/r/1pro/api-tester/tags그리고 이걸 Docker와 Containerd에서 다운로드 받고 이미지 Size를 확인해 볼께요.▶ Docker (490MB)▶ Containerd (248.3 MiB) ※ MB : 10의 거듭제곱을 기준. 1MB는 정확히 1,000,000바이트(10^6 바이트)※ MiB : 2의 거듭제곱을 기준. 1MiB는 정확히 1,048,576바이트(2^20 바이트) 정리하면 이렇게 됩니다.1. Container Image를 만들 때 플랫폼(amd64, arm64)을 고려해야 되는데, Docker에서는 amd64를 받았고, Kuberentes에서 arm64를 받아서 이미지 크기가 달라졌을 것이다.▶ Docker Hub에 올라간 이미지는 amd64 [win, linux]과 arm64 [mac m series]을 지원합니다.)▶ Docker (amd64가 보임)아키텍처 확인#docker image inspect 1pro/api-tester:latest [ { "Id": "sha256:320d6bd226c920f6876939f87cf5d81ea00de92d4e20d226ca73562c1a1a88f6", "RepoTags": [ "1pro/api-tester:latest" ], "RepoDigests": [ "1pro/api-tester@sha256:189625384d2f2856399f77b6212b6cfc503931e8b325fc1388e23c8a69f3f221" ], "Parent": "", "Comment": "buildkit.dockerfile.v0", "Created": "2023-11-25T07:01:31.85143467Z", "Container": "", "ContainerConfig": { "Hostname": "", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": null, "Cmd": null, "Image": "", "Volumes": null, "WorkingDir": "", "Entrypoint": null, "OnBuild": null, "Labels": null }, "DockerVersion": "", "Author": "", "Config": { "Hostname": "", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "ExposedPorts": { "8080/tcp": {} }, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": [ "PATH=/usr/java/openjdk-17/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "JAVA_HOME=/usr/java/openjdk-17", "LANG=C.UTF-8", "JAVA_VERSION=17.0.2" ], "Cmd": null, "Image": "", "Volumes": null, "WorkingDir": "/usr/src/myapp", "Entrypoint": [ "java", "-Dspring.profiles.active=${spring_profiles_active}", "-Dapplication.role=${application_role}", "-Dpostgresql.filepath=${postgresql_filepath}", "-jar", "/usr/src/myapp/app.jar" ], "OnBuild": null, "Labels": null }, "Architecture": "arm64", "Os": "linux", "Size": 520321200, "VirtualSize": 520321200, "GraphDriver": { "Data": { "LowerDir": "/var/lib/docker/overlay2/d57d7d8b06ef8b48164afce5802afad7ac35ba9f13c999c2a38c5bd22462758c/diff:/var/lib/docker/overlay2/660cd2a25be940fb691e195edb1946f135aaff00bd81a59b3978e44802af22e8/diff:/var/lib/docker/overlay2/1f0de966874deedcbc4a04593f0f0ad5486c762c742057c2eb1fb5f9af71a747/diff:/var/lib/docker/overlay2/962edd389f5e5ee4343d585cbcf7c41df43e9d5d77c8d91a300b4ef35f3ace43/diff", "MergedDir": "/var/lib/docker/overlay2/475742e53f8bd9ee4856c12baabb3d11b3d1ee109a69c8202a1a8142a7e17e70/merged", "UpperDir": "/var/lib/docker/overlay2/475742e53f8bd9ee4856c12baabb3d11b3d1ee109a69c8202a1a8142a7e17e70/diff", "WorkDir": "/var/lib/docker/overlay2/475742e53f8bd9ee4856c12baabb3d11b3d1ee109a69c8202a1a8142a7e17e70/work" }, "Name": "overlay2" }, "RootFS": { "Type": "layers", "Layers": [ "sha256:b0d4c4485e7e7fdd7cb6a595a4845c47e39fdfac598fde0fbd8f327423ceb5a0", "sha256:03ee828ef0e49649de4f809d41b8cb2c29e193269f809d3de2a5b6021bc44cec", "sha256:e017d39c755a5133aebbe26075334984cb9a3e18ff9a6790123072fd1f2d3c53", "sha256:34456869abeaa10fe2990423a1b40249e43ae00bc672ff90b5f62b250b271884", "sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef" ] }, "Metadata": { "LastTagTime": "0001-01-01T00:00:00Z" } } ]▶ Containerd (amd64, arm64)가 보임REF TYPE DIGEST SIZE PLATFORMS LABELS docker.io/1pro/api-tester:latest application/vnd.oci.image.index.v1+json sha256:189625384d2f2856399f77b6212b6cfc503931e8b325fc1388e23c8a69f3f221 247.8 MiB linux/amd64,linux/arm64,unknown/unknown - 분석 :해당 Image는 Mac M 시리즈나 Window 유저가 모두 다운받을 수 있도록 만들었습니다. 그래서 한 Image에 amd64, arm64 버전이 각각 있는 거고요.현재 저는 Linux (adm64)에서 이미지를 다운로드를 실행 했고, Docker에서는 amd64 이미지를 받았고, 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보류 3. 쿠버네티스에는 다른 Runtime을 사용 했을 수 있고, 같은 이미지더라도 사용하는 Runtime에 따라서 이미지의 크기는 달라질 것이다.​아래 그림은 제가 강의 [컨테이너 한방정리] 에서 설명 드렸던 그림 입니다.Docker 내부에 Containerd가 있는데, Docker는 정말 많은 기능들을 가지고 있는 고급 레벨의 Runtime이고 실질적으로 Containerd가 컨테이너 만들어 줘요.그리고 쿠버네티스 입장에서는 Runtime으로 Docker나 Containerd 둘중 하나를 선택할 수가 있는데, 예전에는 주로 도커를 사용했지만, 현재는 Contaienrd가 기본으로 사용되고 있어요.​자세한 히스토리는 강의에서 말씀을 드려서 생략하고, 결론적으로 현재 쿠버네티스에서 어떤 Rumtime을 사용하고 있는지 아는 게 중요하고. 이미지 사이즈가 다른 이유는 Docker와 Kubernetes가 아닌 Docker와 Contaienrd의 차이입니다. 결론 :Docker는 다른 많은 기능들을 지원해 주기 때문에 실제 이미지가 248.26MB라고 하더라도 다운 받은 이후 자신의 매타데이터 규격에 맞게 데이터들을 더 추가하고 이미지를 재구성 합니다. 그래서 490MB가 된거고요. Containerd에서 이미지를 가져왔을 때도 마찬가지로, 이미지를 재구성 하느라 Size가 커진 거예요.​반대로 Docker의 이미지를 Contaienrd로 가져가게 됐을 때, Docker에서 재구성을 하느라 커진 불필요한 메타데이터들이 그대로 들어가진 거고요.​이런 사실을 토대로 우리가 하지 말아야 할 일이 있겠습니다.인터넷이 연결되지 않는 환경에서는 이미지들을 다운 받아서 파일 형태로 복사를 해야되요.이때 쿠버네티스에서 Contaienrd를 사용한다면 Docker로 받은 이미지를 복사해 넣을 경우 불필요하게 이미지 사이즈가 커지게 됩니다. 출처Docker와 Containerd 명령 실습 : https://cafe.naver.com/kubeops/137Docker 이미지 사이즈 : https://cafe.naver.com/kubeops/158

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

[강의] 섹션8. Application 기능으로 k8s 이해 - Probe 섹션9. Application 기능으로 k8s 이해 - Configmap, Secret 섹션10. Application 기능으로 k8s 이해 - PV/PVC, Deployment, Service, HPA 섹션11. Component 동작으로 k8s 이해 [미션 진행 소감]2주차..연휴 핑계로 솔직히 놀았다...그래도 그냥 놓으려다가 2주차 미션중 하나라도 일단 해놨는데 발자국 후기 남기는 것도 아닌것 같지만 그래도 남긴다..3주차.. 미션은 안해도좋으니 강의라도 듣고 복습자료를 남기는것으로 목표를 세워야겠다.

인프런워밍업클럽4기 devops - [미션4] PVC/PV, Deployment 실습과제

링크: https://cafe.naver.com/kubeops/49

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

▶ 응용1 : Configmap의 환경변수들을 Secret을 사용해서 작성하고, App에서는 같은 결과가 나오도록 확인해 보세요.☞ Secret을 이렇게 사용하는 경우는 별로 보지 못했습니다. 여러가지 방법으로 Secret을 만들어본다는데 의의를 두시면 됩니다.Step1. Secret 생성 (1) - dashboard ▶ 응용2 : 반대로 Secret의 DB정보를 Configmap으로 만들어보고 App을 동작시켜 보세요☞ Configmap을 Volume에 연결해서 쓰는 케이스는 매우 많습니다. Step1 - Secret 생성 (2) - kubectl #1 Step1 - Secret 생성 (2) - kubectl #2 (이렇게 쓰는건 label 넣기도 불편하고, 명령어 관리가 불편하긴 해요)Step2. Deployment의 envFrom.secretRef 부분 업데이트변경결과▶ 응용2 : 반대로 Secret의 DB정보를 Configmap으로 만들어보고 App을 동작시켜 보세요☞ Configmap을 Volume에 연결해서 쓰는 케이스는 매우 많습니다.Step2. Deployment의 volumeMounts.name과 volumes 부분 업데이트kubectl exec -it api-tester-1231-5c9d747c5c-whjbq -n anotherclass-123 -- /bin/sh

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

▶ 응용1 : startupProbe가 실패 되도록 설정해서 Pod가 무한 재기동 상태가 되도록 설정해 보세요.(여러분들이 가장 많이 겪게될 Pod 에러입니다)☞ startupProbe에 failureThreshold 수치를 App이 기동안되도록 낮추면 됩니다.(Pod가 아닌 Deployment를 수정해 주세요.)startupProbe: httpGet: path: "/startup" port: 8080 periodSeconds: 5 failureThreshold: 1 #수정 readinessProbe: httpGet: path: "/readiness" port: 8080 periodSeconds: 10 failureThreshold: 3 livenessProbe: httpGet: path: "/liveness" port: 8080 periodSeconds: 10 failureThreshold: 3결과 ▶ 응용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-offreadinessProbe: 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 결과 ▶ 응용3 : Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요.(꼭 API를 날리는 것만이 readinessProbe 활용의 전부는 아닙니다)☞ readinessProbe에는 exec라는 속성으로 command를 Pod에 날릴 수 있고, 이는 App기동시 꼭 필요한 파일이 있는지를 체크합니다startupProbe: httpGet: path: "/startup" port: 8080 periodSeconds: 5 failureThreshold: 10 readinessProbe: exec: command: ["cat", "/usr/src/myapp/datasource/postgresql-info.yaml"] periodSeconds: 10 failureThreshold: 3 livenessProbe: httpGet: path: "/liveness" port: 8080 periodSeconds: 10 failureThreshold: 3☞ HTTP 명령이 아니기 때문에 로그에서 Readiness probe가 찍히는건 볼 수 없습니다.☞ 하지만 command 명령에 실패(해당 파일이 없을 때)하면 아래와 같이 event로 실패 로그를 볼 수 있어요

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

발자국 👣[강의] 섹션3. 컨테이너 한방 정리 섹션4. 쿠버네티스 무게감 있게 설치하기 섹션5. 실무에서 느껴 본 쿠버네티스가 정말 편한 이유 섹션7. Object 그려보며 이해하기[미션 진행 소감]1주차 까지는 기존에 들었던 내용이라 다시 한번 들어보니까 한번 더 리마인드 되는 것 같아서 좋았다.[회고]어디에선가 본 글인데 책은 읽으려고 사는게 아니고 사놓았던 책 중에 읽는것이라고 봤다. 이 내용이 나에게는 인프런 강의에 해당된다. 강의를 처음에 사놓을때는 의지가 엄청 불타오르는데 시간이 지나면 점점 의지가 줄어들고 완강률이 적었다. 그래서 이번에 좋은 기회가 있어서 신청하게되었다. 화이팅해보자

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

✅ 아래 글의 내용 및 이미지는 인프런 "쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2" 강의를 듣고 정리한 글입니다. [3-1] Rocky Linux 버전 확인▶ k8s-master 원격접속 후 명령어 실행[3-2] Hostname 확인▶ k8s-master 원격접속 후 명령어 실행[3-3], [3-4] Network 확인▶ k8s-master 원격접속 후 명령어 실행[3-5] 자원(cpu, memory) 확인▶ k8s-master 원격접속 후 명령어 실행[4] Rocky Linux 기본 설정▶ 패키지 업데이트 진행▶ 타임존 설정 확인[5] kubeadm 설치 전 사전작업▶ 방화벽 해제 확인▶ 스왑(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활성화)* 쿠버네티스 문서에 Kubelet의 Cgroup의 Default가 cgroupfs라고 말씀 드렸는데, 레드햇 계열 리눅스의 경우 systemd를 메인으로 프로세스를 실행시키는 시스템이기 때문에, 쿠버네티스 설치시Default로 systemd가 세팅됩니다. 이 경우 containerd도 systemd로 변경하여 모두 systemd를 쓰는게 Core 사용에 부담이 없습니다.▶ cri 활성화 설정 확인▶ kubelet cgroup 확인 (configmap)▶ kubelet cgroup 확인 (kubelet)[7] kubeadm 설치▶ repo 설정 확인▶ SELinux 설정 확인▶ kubelet, kubeadm, kubectl 패키지 설치▶ 설치 가능한 버전의 kubeadm 리스트 확인[8] kubeadm으로 클러스터 생성[Kubernetes Docs] : https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-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 설치 확인