블로그
전체 92025. 06. 24.
1
인프런 워밍업 클럽 4기 Devops 4주차 발자국
helm 처음에 패키지관리할때 공식문서에서 helm차트 사용법을 분석하고 검색하면서 airflow를 설치했던게 새록새록했음그때 문제를 gpt로 찾아가면서 했었는데 자세히 어디서 어떻게 들어가는지 배울 수있게 되었고 값을 추가할 때 어떻게 하는지를 배웠음 메인 템플릿을 두고 value로 값을 조정하는게 좀 혁명적인 것 같음 간단하게 사용하기에는 value만 따로 조정하면되서 configmap과 비슷하다고 느꼈음kustomize 여러 환경이 아니라 단순한 구조에서 오히려 빛을 발하는듯직접 MVP로 만든다거나 기존에 이걸로 구성되어 있으면 많이 쓸것 같음환경이 복잡해지면 값 관리하기가 많이 어려울것 같다argoCD처음에 k8s 배포에 대해 공부했을때는 빌드툴 + argoCD를 접했는데 단 시간 운영에 만 집중해서 깊이 있게 접해보지 못했어서 이번 기회에 기본을 배울 수 있었음배포를 blue/green,canary를 쉽게 할 수 있게 되고 단순 배포를 넘어서 다양한 기능에 있는게 처음알았음 전체적으로 데브옵스 구성할때 어떻게 하면 좋은지 자세히 알려줘서 쉽게 배울수 있었음
2025. 06. 24.
1
[미션5]컨테이너 이미지 사례 실습
docker로 빌드containerd로 빌드
2025. 06. 24.
1
인프런 워밍업 클럽 4기 Devops 3주차 발자국
데브옵스 관점에서 쿠버네티스에 어떻게 배포하고 관리하는지, 젠킨스로 파이프라인을 직접 실습해봄급급히 따라가느라 전체를 다 이해하지 못해서 두고두고 다시보면서 연습이 필요할 것 같음vm에 일반 앱 배포와는 다르게 hpa도 설정해서 부하에 따라 분산도 시킬 수 있고 대용량 트래픽에서 장점이 클 것으로 예상됨그러나 아직 취준생의 입장으로써는 토이 프로젝트에 활용해서 좋은 효과를 보긴 힘들것 같음장점에 따른 단점이 그만큼 만들어야되는 리소스가많음(서비스, 디플로이먼트,볼륨,컨피그맵...)토이 프로젝트는 트래픽 만드는것도 힘들고, 그런 환경을 운용할 자금도 부족함, 필요성도 부족해지는 것 같음전에는 깃 액션으로 aws와 gcp에 배포했음젠킨스와는 조금 비슷하면서도 많이 다름깃에서 직접 소규모로 쓰기에는 깃액션이 좀더 좋은듯함(쉽고 쓸수 있는 템플릿도 있음)보안이나 온프렘이면 깃액션은 쓰기 어려울 수 있으니 이때는 젠킨스가 좋을 것 같음 젠킨스의 어느부분에서 어떻게 가져오면 되는지 더 자세히 알아보고 정리해놓는게 좋을듯함 todo- 젠킨스와 gitaction 장단점 비교- 상황에 따른 k8s 장점 실제로 느껴보기
2025. 06. 10.
0
[미션4] PV/PVC, Deployment.. 실습과제 제출
1. PV, PVC▶ 1~4. local 동작 확인▶ 5. hostPath 동작 확인 - Deployment 수정 후 [1~4] 실행2. Deployment ▶ 1. RollingUpdate 하기▶ 2. RollingUpdate (maxUnavailable: 0%, maxSurge: 100%) 하기▶ 3. Recreate 하기3. Service ▶ 1. Pod 내부에서 Service 명으로 API 호출 [서비스 디스커버리]▶ 2. Deployment에서 Pod의 ports 전체 삭제, Service targetPort를 http -> 8080으로 수정▶ 2. 그리고 다시 Pod 내부에서 Service 명으로 API 호출 4. HPA▶ 1. 부하 발생후 확인(늘어나고 줄어나는 사진)[behavior] 미사용으로 적용▶ 2. 부하 발생후 확인
2025. 06. 10.
1
[미션3] Configmap, Secret 응용과제
▶ 응용1 : Configmap의 환경변수들을 Secret을 사용해서 작성하고, App에서는 같은 결과가 나오도록 확인해 보세요. ▶ 응용2 : 반대로 Secret의 DB정보를 Configmap으로 만들어보고 App을 동작시켜 보세요
2025. 06. 10.
0
[미션2] Probe 응용과제
▶ 응용1 : startupProbe가 실패 되도록 설정해서 Pod가 무한 재기동 상태가 되도록 설정해 보세요.기존 pod을 두고 새로운 pod을 만든다새로운 pod이 startupProbe 실패 횟수 1회면 실패로 되기 때문에 무한 재기동된다기존 pod은 새로운 pod이 완벽히 만들어지지 않았기때문에 계속 꺼지지 못하고 있다▶ 응용2 : 일시적 장애 상황(App 내부 부하 증가)가 시작 된 후, 30초 뒤에 트래픽이 중단되고, 3분 뒤에는 App이 재기동 되도록 설정해 보세요.트래픽 중단 로그 3분뒤에 재가동하는 로그 ▶ 응용3 : Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요.["cat", "/usr/src/myapp/datasource/postgresql-info.yaml"] 해당 명령어가 yaml에서 두줄로 인식되면서 정상적으로 인식해서 땀 흘렸는데 직접 cat /usr/src/myapp/datasource/postgresql-info.yaml 형태로 수정했다
2025. 06. 08.
1
인프런 워밍업 클럽 4기 Devops 2주차 발자국
금주 강의 한내용 probe,configmap,secret,pv/pvc,Deployment, Service, HPAprobe처음 probe를 접했을 때 fail이 되는것을 보고 시스템이 뭔가 잘못깔렸나라고 생각들었다 그런데 일부러 그렇게 동작한 것이었고, 실제로 문제가 있었으면 pod 자체가 초기화되서 생성된다는 걸 배웠고 k8s라는 시스템이 pod 상태를 어떻게 관리하는지 배울 수 있었다.configmap설정 자체를 helm차트로 설치하면서 value를 따로 빼서 설정값을 주입시켰는데 k8s configmap 해당 value와 k8s상에서 사용하는 오리지널 오브젝트인것 같다역할은 비슷해보이는듯 ?do next: helm chart에서는 configmap을 안쓰고 value를 쓰는지 찾아볼것 secretairflow 헬름차트 따라서 github repo의 키를 쓸 때는 secret으로 등록해서 사용했지만 생각보다 보안에 취약한 것을 배울 수 있었다. 하지만 공식 airflow에서는 secret으로 등록하라고 주석이 달려있었던걸로 기억한다 do next: secret의 대안을 찾아보고 사용법 익히기 pv/pvc처음에 eks에서 실습할때 airflow에서 볼륨이 잘 지정되지 않아서 됐던걸로 기억한다 왜 이렇게 되지 생각되는 부분이 많았는데 인프라와 개발 책임을 나눌려고 하는게 보였다Deploymentk8s에서 가장 꽃이라고 생각할 deployment이다 기존 도커에서 가장 다르고 k8s에서 제일 처음 만나게 되는 오브젝트인것 같다소규모로 토이프로젝트할때는 사실 그렇게 효용성이 크게 느껴지기 어려웠는데 확실히 큰 서비스를 배포하고 트래픽을 많이 받을 때 중요해지는 것 같다 단순히 배포에서 여러 pod을 운영하다를 넘어서 배포전략을 어떻게 설정하는지 새로 배웠던 것 같다 Service몰랐던 것보다 어떻게 동작하는지 다시 생각해볼 수 있었다 처음 단순히 노드포트로써 외부 포트와 연결하는정도로 사용했었는데 인그레스 설정도 있고 LB로 사용할 수 있고 깊게 알면 사용할 곳이 많아 보인다 HPAauto scaling이란 개념은 aws에서 ec2를 다뤄보면서 공부했었는데 리소스를 세부적으로 계획을 할 수 있는것에 신기했다 기초에서는 HPA 개념이 중요하지 않고 어느정도 트래픽이 넘었을때 중요해지는데 이런 기능도 있다는게 처음 배웠고 필요하면 추후에 배워봐야겠다
2025. 06. 01.
1
인프런 워밍업 클럽 4기 Devops 1주차 발자국
이번주 학습한 내용리눅스의 역사 k8s의 overview 컨테이너가 만들어지는 흐름학습회고전반적으로 큰 흐름을 이해할 수 있어서 좋았어요과정자체를 이해할 수 있고 이유를 배울 수 있어서 좋았습니다처음 쿠버네티스를 접했을때 yaml파일 같이 선언형으로 관리한다는게 신기했는데 실무와 실습중심이라 그런지 그런 부분이 언급이 없어서 새로웠어요 복습 듣기는 들었지만 복습할려고 정리할려니까 머리가 너무 복잡해지네요 다 넣고싶은데 너무많은것 같고 ..ㅠㅠ쉽게 쉽게 더 덜어내서 복습글을 마무리하는게 차주의 목표에요 미션 vm에 처음부터 설치하는 과정을 했어요깊게 이게 왜 이런 코드가 되고 왜 필요했는지 생각해보고 싶었는데 생각보다 설치 과정이 길어서 그렇게 하기가 시간이 여유가 아쉽네요 다음번에 시간내서 한번 분석하고 다시 따라가봐야 되겠네요
2025. 05. 31.
1
[미션1] 구간별 상태 확인
[3-1] Rocky Linux 버전 확인[3-2] Hostname 확인[3-3], [3-4] Network 확인[3-5] 자원(cpu, memory) 확인[4] Rocky Linux 기본 설정▶ 타임존 설정 확인[5] kubeadm 설치 전 사전작업▶ 방화벽 해제 확인▶ 스왑(swap) 비활성화 확인[6] 컨테이너 런타임 설치[6-1] 컨테이너 런타임 설치 전 사전작업▶ iptables 세팅[6-2] 컨테이너 런타임 (containerd 설치)▶ docker repo 설정 확인▶containerd 설치 확인▶설치 가능한 버전의 containerd.io 리스트 확인 [6-3] 컨테이너 런타임 (CRI활성화) ▶ kubelet cgroup 확인 (configmap) ▶ kubelet cgroup 확인 (kubelet)[7] kubeadm 설치▶ repo 설정 확인 ▶ SELinux 설정 확인▶ kubelet, kubeadm, kubectl 패키지 설치▶ 설치 가능한 버전의 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 자동완성 기능[9-2] Dashboard 설치 [9-3] Metrics Server 설치