블로그

최신순
인기순
좋아요순

[kubernetes] 쿠버네티스 첫 오브젝트 잘 끼우기 #6

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 : https://inf.run/NzKy 오늘 공부할 내용이 쿠버네티스에서 사용되는 오브젝트들의 한 20% 정도가 되지 않을까 싶어요. 그동안 공부한 양이 적지도 않았고언제 쿠버네티스를 다 배우나 무거운 마음일 수도 있는데 제가 좀 안심이 되는 얘기를 드리면..혹시 파레토의 법칙 이라고 들어보셨나요? 예를들어, 우리나라의 20% 인구가 80%의 땅을 갖고 있다던가, 회사에 100명이 일하고 있는데 20명이 사실 그 회사에 80% 일을 하고 있다는 거죠. 수학적으로도 증명 가능한 말이라고 하고요.결국 원인의 20%가 80%의 결과를 만들어낸다는 뜻인데 저는 이번 강의를 이렇게 말씀드릴 수 있을 것 같아요. 오늘 배울 20%의 오브젝트들이 앞으로 쿠버네티스에서 자주 쓰는 오브젝트의 80% 입니다. 그렇기 때문에 오늘 강의가 정말 중요하고 이번 블로그도 끝까지 잘 읽어 주시길 부탁 드릴게요. 이번 강의는 제가 오랜 시간 걸려서 쿠버네티스를 이해했던 단계들을 바탕으로 구성을 한 거고요. 오브젝트를 잘 이해하는 방법으로 세 가지 단계를 준비를 했습니다.쿠버네티스의 어떤 기능은 그림을 그려볼 때 이해가 쉽고, 어떤 기능은 실제 App이랑 동작을 하는 걸 봐야지 이해가 정확해요. 그리고 어떤 기능은 쿠버네티스 내부 동작을 아는 게 중요한데, 이번 수업에서는 [Object 그려보며 이해하기]만 다룰 거고요. Object 그려보며 이해하기카페 실습 자료실 링크 (link) 이 단계에서는 위 강의 자료실에 실습으로 사용될 yaml 파일을 읽어보면서 오브젝트들을 하나씩 그려보고, 각 오브젝트들에 대한 역할이나 기능들을 살펴보겠습니다.이제 Object들을 하나씩 그려 보면서 역할이나 기능들을 간략하게 설명을 드릴게요.Namespace를 보면 Namespace는 Object들을 그룹핑 해주는 역할이에요. 그리고 metadata에 name이랑 label이 있는데 일단 그림만 그려놓고 넘어갈게요.그리고 다음으로 Deployment는 Pod를 만들고 업그레이드를 해주는 역할이구요. 여기에 namespace로 위에서 만들었던 이름이 있죠? 이렇게 하면 이 Deployment는 이 Namespace에 소속이 됩니다. 그리고 여기 이름이 있는데 한 namespace 안에서 이 이름은 중복이 되면 안되요. 그리고 label이랑 이 selector는 앞으로 계속 나올텐데 한번에 정리를 해서 설명을 드릴 거라 일단 이런 게 있다고만 알고 넘어가고요.그리고 replicas는 pod를 2개를 만들라는거고 strategy의 RollingUpdate는 deployment 기능의 핵심인데, 이 업데이트 방식에 대해서는 다음 강의에서 실습으로 해볼거에요. 그리고 template 부터가 이 내용대로 pod가 만들어진다고 보면 되는데, nodeSelector는 pod를 띄울 노드를 선택하는 거고 containers라는 속성이 있고 그 밑에 옵션들이 쭉 있는데 이 image는 제가 DockerHub에 이 이름으로 컨테이너 이미지를 올려놨기 때문에 여러분들이 이 image에 이렇게 넣으면 다운을 받아서 쓸 수 있는 거예요. 그리고 밑에 envFrom가 있고 configmap과 연결이 되어 있는데, Application에 환경 변수랑 관련된 부분이고 configmap은 그 값을 제공해 주는 역할을 해요.그 밑에 프로브들이 3개가 있는데 startupProbe는 App이 잘 기동이 됐는지 체크를 하고 있다가 기동이 안 되면 App을 재기동시키고요. 잘 됐으면 이 밑에 readinessProbe랑 livenessProbe를 시작 시켜요. 그래서 readinessProbe는 App에 트래픽을 연결 할 건지를 결정하는 속성이고 이 livenessProbe는 App이 정상이 아니면 재시작을 시킬 건지 판단하는 속성이에요. 정말 중요한 속성이고 이건 실제 App기능을 보면서 자세히 이해를 해 볼 거고요.다음으로 resources는 pod에 CPU랑 memory를 할당을 시킬 거고 최대 limit까지 쓸 수 있다는 설정이 있는데 이걸 설정하지 않으면 pod가 노드의 자원들을 모두 써버리게 됩니다.그리고 volumeMounts가 있는데 이 mountPath는 pod 내부에 만들어지는 디렉토리이구요. 이 이름이랑 volumes에 이 이름이 매칭이 되서 실제 persistentVolumeClaim이라는 object랑 연결이 되는 거에요. 그리고 secret-datasource도 이렇게 name으로 연결이 되면서 secret object랑 연결이 됩니다. 다음으로 Service고요. 이렇게 metadata 3세트는 자주 나올 거예요. namespace에 속한 object고 name이랑 labels이 있죠. 그리고 밑에 selector랑 ports, type이 있는데, 이 Service의 역할은 pod한테 트래픽을 연결시켜 주는거에요. 근데 이름을 보면 한 namespace안에는 이름이 중복되면 안 된다고 했잖아요? 정확히는 같은 종류의 object끼리 이름이 같으면 안 되는 거예요. 그래서 Service랑 Deployment는 서로 다른 object라 이름이 같아도 되고요.이제 ConfigMap을 보면 pod의 환경변수 값을 제공하는 역할이고요. 이렇게 metadata 3세트랑 그리고 data가 있는데 이게 아까 말했던 환경변수로 들어갈 값의 내용이에요. 그리고 밑에 Secret도 ConfigMap이랑 비슷한데 pod에 좀 더 중요한 값을 제공하는 역할로 쓰여요. 다음 강의에서 App기능을 실습을 해보면서 좀 더 이해를 해 볼게요. 여기서는 data가 아니고 stringData가 있는데 좀 다르죠? 이렇게 쓰면 stringData 내용들이 pod 안에 파일로 만들어집니다. 그리고 PersistentVolumeClaim이 있고 pod에서 pv를 지정할 때 사용을 하는데, 밑에 저장 공간을 얼마나 사용할지 그리고 이 저장 공간의 accessModes로 읽기/쓰기가 가능하다는 옵션이 있는데, 이 내용은 이번 실습에서는 동작하지 않고요. 그냥 필수값이라서 넣어둔 거라 다음번에 Volume만 다루는 강의에서 다시 설명을 드릴게요. 이번 실습에서는 selector만 쓰입니다.그리고 다음으로 PersistentVolume인데, 실제 Volume을 지정하는 역할을 하고요. 근데 여기에는 namespace가 없죠? 이 object들의 가장 큰 범위가 Cluster거든요. Namespace도 Cluster 안에 속해 있는 object고요. PV도 여기에 만들어지는데,object들은 크게 두 분류로 나뉘어요. Namespace랑 PersistentVolume은 Cluster Level의 Object라고 하고요. Deployment랑 Service들은 Namespace Level에 Object라고 해요. 그리고 각 object들은 자신의 level이 있기 때문에 Deployment는 PV처럼 Cluster level에 만들어 질 수가 없습니다.다시 PV로 돌아와서 마찬가지로 이런 내용들은 일단 넘어가고, local이 중요한데 path를 volume으로 사용하겠다는 내용이에요. 그리고 그 대상 노드는 밑에 nodeAffinity가 있는데, 좀 복잡해 보이지만, nodeSelector랑 똑같이 결국 Master Node를 지정한다는 내용입니다. 그래서 여기에 path가 사전에 없으면 PV를 만들 때 문제가 생기기 때문에 디렉토리를 미리 만들어 준 거고요. 그리고 이제 마지막으로 HPA인데, 부하에 따라 pod를 늘려주고 줄여주는 스케일링 역할을 하구요. scaleTargetRef로 그 스켈링 대상을 지정을 하고, min/maxReplicas는 최소 두 개의 pod를 유지를 하고 있다가 부하가 생기면 최대 4개까지 늘어나도록 설정을 한 거예요. 그리고 metrics라는 설정은 pod의 cpu가 평균 40%가 늘어나면 스케일 아웃을 하라고 설정을 한 겁니다. 그리고 밑에 behavior는 pod가 한번 증가를 한 후에 600초, 그러니까 10분 동안 또 pod가 추가적으로 늘어나지 않게 하는 설정인데, pod가 2개에서 3개로 늘어나자마자 부하가 더 증가한다고 해서 바로 4개로 늘리고 싶진 않을 때 이런 설정을 해요.그리고 마지막으로 namespace에 대한 기능을 하나 더 말씀드리면, namespace를 삭제하면 이 안으로 만든 모든 object가 같이 삭제가 되거든요. 그래서 실습을 하고 강의에서 배포한 object를 모두 삭제를 할 때는 이 namespace를 삭제하는 명령 하나만 날리면 되구요. PV는 namespace에 속하지 않기 때문에 별도로 한번 더 삭제를 해 줘야 되요.그럼 여기까지 오브젝트들을 봤는데 지금 좀 혼란스럽고 이해가 안되는 상황이라면 그게 맞아요. 현재까지는 각 object들이 어떤 역할을 하는지 대략적인 느낌만 이해를 하면 됩니다 :) Object 그려보며 이해하기 - (label/selector/naming) (1)제가 대리 때, 팀에 차장님 한 분이 새로 들어오셨는데, 같이 일 한지 한 두 달이 넘었을 때였어요. 옆팀 부장님이 저한테 새로 온 차장님 이름을 물어보시더라고요. 근데 저는 평소 강차장님이라고만 불러서 이름은 처음 인사를 할 때 듣고 까먹은 상태였거든요. 나중에 확인해 봐야지 하면서 차일피일 미루고 있었는데, 다행히도 이 부장님께서는 제 대답에 딜레이를 느끼시고 바로 다른 분한테 물어봤습니다. 근데 저는 이 상황이 많이 부끄러웠어요.여러분도 이렇게 시간이 어느 정도 지났을 때 모르고 있으면 부끄러워지는 상황들이 있지 않나요?지금부터 배울 이 내용이 바로 그런 느낌이에요. 저도 실제로 쿠버네티스를 시작하고 2년 정도가 지나서야 이 부분을 신경쓰기 시작했는데, 해당 내용은 강의 영상에서 잘 설명을 드릴 예정이고 여러분들은 부디 저와 같은 실수를 하지마시고 잘 챙기시길 당부 드릴께요. Object 그려보며 이해하기 - (label/selector/naming) (2)여기까지 읽으시느라 정말 수고하셨고요. 처음 이런 내용을 들으시는 분께는 뭔가 많은 내용처럼 보일 수도 있지만 정말 자주 쓰는 기능들이고, 조금만 쓰다 보면 금방 익숙해지는 부분들이니까 너무 부담 갖지 마세요.그럼 오늘 블로그는 여기까지 마치겠습니다. ps. 뒤로가기 함부로 누르지마라. 너는 누구에게 한 번이라도 좋아요♡를 준 사람이었느냐 :)

데브옵스 · 인프라･인프런･쿠버네티스･어나더클래스･지상편･일프로･kubernetes･devops･kubeops･첫오브젝트잘끼우기

[쿠버네티스] 컨테이너 한방 정리 #3

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 : https://inf.run/NzKy 기술의 흐름으로 이해하는 컨테이너 쿠버네티스는 이제 [컨테이너]랑 [가상화] 그리고 [데브옵스]속에 깊숙히 자리잡고 있습니다. 그래서 이 세 가지를 알아야 쿠버네티스를 더 잘 알 수 있게 되는데, 이 단어들은 정말 큰 개념이라서 그냥 용어 설명으로는 이해하기 힘들어요. 그래서 기술에 전반적인 배경을 이해하는 게 중요하다고 생각합니다.그래서 이번 강의는 [컨테이너 한방 정리]로, 쿠버네티스를 잘 이해하기 위해 컨테이너를 중심으로한 여러 배경 흐름 들을 이야기 해요. 1. Linux OS 흐름컨테이너를 잘 알기 위해서는 Linux에 대해서 먼저 알 필요가 있습니다. 최초에 OS로 unix가 있었고, 한참 시간이 지나고 linux가 나왔어요. 그리고 이 linux를 기반으로 현재까지도 엄청 많은 배포판들이 만들어지고 있습니다.하지만, 다행이도 우리는 이 두 가지 배포판만 알고 있어도 충분해요. debian이랑 redhat 계열인데, debian linux는 커뮤니티용이라고 해서 무료고요. redhat linux는 redhat 이라는 기업에서 만들었고, 유료에요.쿠버네티스를 설치할 때도 이렇게 이 두가지 배포판을 기준으로 설치 가이드를 제공합니다. 데비안과 레드햇 계열에 대한 자세한 얘기는 강의 중에 설명드리고, 여기선 기업용으로 쓰는 redhat에 대해 좀 얘기를 해볼께요. redhat에서 linux 배포판이 만들어지는 순서가 있어요. 최초에는 fedora linux라고 해서 새로운 기능을 개발하는 버전이 있고, 이건 무료고요. 이 기능들이 안정화되면 redhat linux로 이름을 바꿔서 릴리즈를 합니다. 기업은 이걸 설치하면 유지보수 비용을 내야되는 유료 버전이고, redhat enterprise linux 앞자만 따서 RHEL, 렐 이라고도 통상 불러요. 그래서 이걸로 기업들이 설치를 하면 유지보수 비용을 내야 되는 유료 버전 이고, 그리고 이걸 복사해서 만든 게 centOS 배포판 이예요. rhel이랑 똑같이 안정화 버전인데, 무료로 쓸 수 있습니다.기업에서는 주로 redhat 계열을 많이 쓰고, 특히 centOS의 점유율이 높은데 centOS 8은 2021년에 지원을 종료 했고, centOS 7은 2024년도에 지원이 종료가 되거든요. 이 centOS가 종료되는 배경을 좀 말씀을 드리면 시장 점유율이 ubuntu가 압도적이고. 다음은 centOS랑 debian이 2, 3위를 왔다갔다 해요. redhat은 2%지만, 이 수치가 그래도 기업 배포판 중에 1위고요. 이 1위가 된 배경에는 사람들한테 centOS를 무료로 쓰게 해주면서 자연스럽게 redhat을 선택하게 하는 그런 전략이 있었거든요. 근데 현재 redhat은 IBM에 인수가 된 상태예요. 그리고 IBM의 새로운 전략은 centOS에 점유율을 rhel로 당기려는거 같아요.왜나하면 현재 redhat 배포판을 만드는 순서가 이렇게 변경됐거든요.처음엔 마찬가지로 fedora를 통해서 기능 개발을 하고, centOS대신 centOS Stream이라고해서 이 기능들을 테스트하는 배포판이 생겼어요. 테스트 배포판(테스트베드)이라고 생각을 하면 되는데 여전히 무료지만, 이 배포판에서는 바이너리 호환성 보장 안될 수 있다는 얘기를 해요. 무슨 내용인지 몰라도 이제 쓰면 안되나 싶은 생각이 들죠?그리고 테스트 과정이 끝나면, 안정화 버전인 Redhat Linux가 됩니다. 이렇게 배포판을 만드는 프로세스가 바꿨어요. 그래서 기존에 centOS를 쓰던 기업들은 앞으로 고민을 좀 해봐야 되는 게 지금 상황이고요. 아래와 같이 4가지 방법이 있는데 아래와 같습니다.이렇게 4가지 선택지 중에 전 4번을 선택을 했고, 이 강의에 실습 환경으로 사용이 되요. 저도 어떤 linux를 선택할까 고민을 많이 했는데, 1, 2번은 기업의 상황이라 제외를 하고, 타 OS로 ubuntu를 고민을 하다가 그래도 제가 가장 오래 사용을 했고, 문제가 생겼을 때 잘 가이드를 해드릴 수 있어야 하니까 4번, 새로운 복제본을 선택을 했습니다.그리고 AlmaLinux와 RockyLinux 중에서 Rocky Linux를 선택한 이유는 아래와 같아요.구글 트렌드에서 키워드 검색량 확인 (link)CentOS 공동설립자 중 한명 만들었음 (link)클라우드 서비스에서 VM 생성을 Rocky Linux로 하는 사례들 확인Github Watch/Fork/Start 비교 (rocky link), (alma link) 2. Container 흐름자, 이제 컨테이너에 대해서 얘기를 해 볼꺼예요. 지금까지 봐듯이 linux는 꾸준히 발전을 했고, 내부적으로도 많은 코어 기술들이 개발이 됐는데 그중 하나가 격리 기술이예요.chroot라고 해서 사용자 격리를 시작으로 파일이나 네트워크를 분리하는 기술들이 만들어 졌고요. 한참 지난 후에 cgroup이라고해서 각각에 App마다 cpu나 memory를 할당을 할 수 있게 됐어요. namespace는 보통 App 하나가 하나의 프로세스를 차지하거든요. 이 프로세스를 격리 시켜주는 기술이 만들어 지면서 우리는 이제 각각의 App을 소위 말하는 [독립적인 환경]에서 실행을 시킬 수 있게 됩니다.그리고 다음으로 이 기술들을 집약해서 정리한게 LXC라고 해서 linux container에 줄임말 이예요. 이 컨테이너의 어머니이자, 최초의 컨테이너죠. 그리고 이 기술을 기반으로 만들어진 이번엔 컨테이너에 대명사죠. Docker, 요즘은 위세가 많이 죽긴 했어요. 이전까지 컨테이너 기술은 저 같은 평범한 개발자들이 쓰기엔 좀 어려웠다면 docker는 이걸 누구나 쓰기 쉬운 형태로 만들었습니다. 요즘 잘 정리된 블로그 몇 개만 봐도 대강 이해해서 내 OS에 컨테이너를 띄울 수 있죠.docker가 나오고 rkt라고 rocket이라는 컨테이너가 나와요. docker가 보안에 안 좋은 점이 좀 있는데, 이 부분을 공략을 하면서 더 안정적인 컨테이너를 강조를 했고 실제 docker보다 성능도 더 좋다고 해요. docker가 보안에 안 좋은 점은 root권한으로 설치하고 실행을 해야 되기 때문인데, 현재는 rootless 설치 모드가 생겨서 보안이 강화가 됐습니다.한편 쿠버네티스는 점점 표준으로 정착이 되고 있고, 현재는 컨테이너간의 싸움 중입니다. 초반에 docker가 보안에 약하다는 것 까지는 사실 docker 대세에 크게 문제가 없었거든요. 시간이 지나면 충분히 보완 될꺼라는 기대도 있었고 실제로 보완이 됐죠. 근데 docker 위세가 조금씩 꺽이기 시작한 이유가 뭐냐면, 쿠버네티스에서 docker가 빠진 다는 얘기가 계속 있었어서 그래요. 그 이유는 docker가 쿠버네티스와 인터페이스가 잘 안 맞아서 그렇거든요. 물론 처음엔 docker를 메인으로 쿠버네티스가 만들어졌죠. 근데 쿠버네티스가 표준화가 될 수록 docker가 걸림돌이 되고 있는 상황이예요. 이제 누가 쿠버네티스랑 호환성이 좋은지가 컨테이너를 선택하는 중요한 결정요소가 됐습니다.그 이후에 나온 대표적인 컨테이너가 containerd랑 cri-o고요. containerd는 docker에서 컨테이너를 만들어주는 기능이 분리된 거예요. docker가 설치할 땐 간단해 보여도 엄청 많은 기능들이 녹아진 엔진이거든요. 그 큰 엔진에서 containerd 프로젝트만 분리 되서 나왔고 CNCF에 기부 됩니다. 번외로, docker는 현재 mirantis라는 회사에 인수된 상태예요. docker를 정말 많이 쓰지만 기술 투자 대비해서 수익이 큰 편은 아니었던 거 같아요. 그래서 mirantis라는 회사에 인수가 됐고 이 mirantis는 openstack 프로젝트를 하고 있는 회사 거든요. 이 openstack이 뭐냐면, kubernetes 이전에, 가상화에 대세라고 하긴 좀 그렇고, 가장 큰 가능성으로 가상화 시장을 선도한게 openstack 이예요. 저도 개인적으로 한 3년 정도 openstack 관련된 일을 했었고, 그래서 다음 가상화를 설명하는 강의에서 최대한 재미있게 얘기를 해 드릴께요. 여튼 docker가 mirantis에 인수된 이후부터 이 kubernetes 인터페이스를 잘 맞추려고 하고 있기 때문에 쿠버네티스에서 docker는 빠지진 않게 됩니다. 3. Container Orchestration과 Container 흐름강의 영상에서 컨테이너 오케스트레이션(쿠버네티스)과 컨테이너(컨테이너 런타임) 간에 한 단계 더 깊은 흐름을 이야기 합니다.가장 핵심은 쿠버네티스의 kubelet 변화와 그리고 이에 따른 컨테이너 런타임들 간의 흐름이예요. 바로 CRI가 어떤 배경에서 만들어졌고, 쿠버네티스 버전이 올라가면서 CRI가 어떤 방향으로 바뀌는지, 그리고 그에 따른 컨테이너 런타임들 간의 변화를 설명드립니다. 그리고 컨테이너에서 절대 빼놓으면 안되는 OCI가 있습니다. 컨테이너 표준인데, 컨테이너 런타임들은 이걸 잘 지키고 있기 때문에, 우리는 런타임을 바꾸더라도 기존에 만들었던 이미지를 그대로 사용할 수 있어요 블로그는 여기까지고요. 강의가 오픈 되면 링크 걸어 놓을께요.좋은 하루되세요! 좋아요 ♡는 저에게 큰 힘이 됩니다 :)

데브옵스 · 인프라･인프런･쿠버네티스･어나더클래스･지상편･일프로･kubernetes･devops･kubeops･container･컨테이너한방정리

[kubernetes] 실무에서 느껴본 쿠버네티스가 정말 편한 이유 #5

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 : https://inf.run/NzKy 저는 개발자로써 SI 프로젝트를 많이 했습니다. 그리고 제가 겪은 SI에 대해서 얘기 드리면..일단 개발에만 몰두할 수 있는 시간은 별로 없어요. 제안서 쓰고, 업무 프로세스 분석하고, 단계별 문서를 만들고 상황에 따라 인프라 구축도 하고, DB부터 Web Front까지.. 프로젝트 오픈에 필요한 많은 걸 경험해 봤어요.물론 이것도 하다 보면 익숙해지는 부분도 있지만 그래도 매번 SI프로젝트를 힘들게 만드는 요인이 뭐냐면하나는 매번 다른 업무 프로세스에요. 고객사마다 업무 프로세스가 다르니까 매번 새 업무를 분석하느라 고생을 하게 되고요. 그리고 변화가 빠른 웹 기술이에요. 웹 분야는 발전 속도가 빠르고 신 기술이 많아서 프로젝트를 할 때마다 같은 기술로 웹 페이지를 만들어 본 적이 별로 없었던 것 같아요. 그래서 매번 새로운 기술을 공부해야 됐고. 마지막으로 다양한 기술 솔루션 적용인데, 모니터링이나 로깅, 암호와 같은 솔루션이 고객사마다 쓰는 제품들이 다르고요. 비용 절약 때문에 개발자가 직접 해야 되는 경우도 비일비재해요. 그래서 이것도 매번 새 솔루션을 적용하는 법을 익혀야 됐습니다.더 많지만 이렇게 이번 프로젝트에서 고생을 해서 기술을 익혀도 다음 프로젝트는 또 고생을 하게 되더군요.하지만, 개발자가 아닌 쿠버네티스 엔지니어로서 SI프로젝트는 할만 했습니다.무엇보다 프로젝트가 반복될 수록 일은 더욱 쉬워졌는데, 이번 강의에서 [쿠버네티스 표준 생태계로 편해진 IT인프라 구축], [쿠버네티스 기능으로 편해진 서비스 안정화], [인프라 환경 관리의 코드화]를 주제로 그 이유를 자세히 설명 드려요.쿠버네티스 표준 생태계로 편해진 IT인프라 구축쿠버네티스가 나온 지 10 년도 안 됐는데, 현재 이렇게 많은 제품들이 쿠버네티스 생태계 위에서 돌아가요.IT에 관련된 모든 회사가 쿠버네티스와 컨테이너에 진입을 했다고 해도 과언이 아닐 정도인데, 이미 많은 회사들은 컨테이너가 미래에 인프라가 될 거라는 걸 예상했고 너도나도 이 시장의 넘버원이 되려고 뛰어 들었어요. 그 결과 정말 짧은 시간만에 쿠버네티스 기반의 IT 생태계가 이렇게 폭발적으로 커졌습니다.여러분 지금 기업에서 대부분 자바로 개발을 하잖아요. 자바가 95년도에 처음 만들어졌고 10년 뒤에 이걸로 스프링이 나왔어요. 그리고 또 5년이 지나서야 확산이 되기 시작한 건데, 그에 비해 쿠버네티스는 정말 이례적이라고 할 수가 있죠.근데 이 그림을 보면, 아 이제 늦었나? 쿠버네티스를 하려면 이렇게 많이 알아야 돼? 라고 오해를 할 수가 있을 것 같아요. 뭔가 많아 보일 순 있는데 점점 제가 단순화를 시킬 거니까 걱정 마시고요.CNCF에서 이 클라우드 생태계를 영역별로 카테고리화 시켰는데,[개발]은 기존부터 해왔던 App 개발에서 배포까지 써야되는 기술들 이고요. [오케스트레이션 / 매니징]은 이 App을 마이크로 서비스로 만들 때 쓰면 좋은 기술들이에요. 그리고 [플랫폼과 런타임]은 이 App을 클라우드로 올릴 때 주로 사용되는 기술들이 많고요. 그리고 [프로비저닝이랑 분석]은 실제 프로젝트에서 써야 되는 기술들이 있어요.만약에 프로젝트에서 App을 마이크로 서비스로 개발하고 클라우드까지 올린다면 여기 있는 카테고리를 다 알아야 되고 근데 요즘은 이런 프로젝트가 대부분이죠 :)그나마 불필요하다고 생각하는 부분은 그리고 밑에 [스페셜]은 쿠버네티스 관련 업체들이랑 교육 파트너고요. [서비스]랑 분석 쪽에 [카오스 엔지니어링]이랑 [최적화]부분은 메인 영역은 아니라서 과감히 빼버리겠습니다. 그리고 전체 그림을 다시 보면..아까보단 좀 나아진 거 같나요?이미지들이 살짝 눈에 보이는 거 같기도 하고요. 그래도 아직 쿠버네티스를 하기 싫어지는 그림이에요. 여기서 이제 디테일하게 줄여나가 보겠습니다. CNCF에 기여된 프로젝트는 성숙도에 따라서 이렇게 4가지 종류가 있는데, Sandbox는 아직 실험 단계라서 우리가 안 쓰게 될 확률이 커요. 그리고 그 밑에 Archived는 프로젝트가 비활성화 된 거에요. 그래서 더 이상 기술 지원이 없는 프로젝트니까 이 두 가지를 빼고요.CNCF에서 성숙도가 높다고 우리가 많이 쓰고 있는 건 아니거든요. 그래서 Graduated지만 Github에 Stars 수가 낮은 건 제외를 하고 Incubating 이지만 Stars 수가 높은 건 포함해서 보면..이정도가 있네요. 그리고 CNCF에 기여된 프로젝트 외에 CNCF 멤버와 비멤버 제품들도 있어요. 멤버와 비멤버의 차이는 CNCF에 회비를 내면서 제품 홍보나 등급별로 혜택을 받을 수 있나없나의 차이일뿐이고, 그래서 비멤버라도 표준 생태계에 영향력 있는 제품들이 많습니다.그래서 CNCF 멤버/비멤버 제품들 중 Github에 Stars 수가 높은 걸 골라보면.. 이 정도로 정리가 돼요. 이제 이렇게 추린 내용을 다시 이쁘게 정리해보겠습니다. 참고로 제가 짬으로 몇 개 추가/삭제한 것도 있어요.CNCF landscape 중 선별 기준CNCF 프로젝트 : Graduated Projects (Github Stars 낮음 제외), Incubating Projects (Github Stars 높음 추가), Sandbox Projects (X), Archived Projects (X)CNCF 멤버/비멤버 제품 : 깃허브 Stars 높음 추가, 일프로 임의 추가참고 링크 : CNCF (link), CNCF landscape (link) 이제 좀 그림이 보이기도 하고, 안구 정화가 되죠?눈에 잡히는 IT생태계를 보여 드리려고 이렇게 정리를 해 봤는데, 사실 CNCF를 졸업했고 멤버가 어떻고는 중요하지 않아요. 그리고 제가 이 정리된 그림을 먼저 보여 드려도 되는데 이런 선별 과정까지 보여 드린 이유가 있습니다.이 오픈 소스들을 공부하게 될 때 이것만 잘 깊이 있게 보면 좋은데 갑자기 누가 요즘 뭐가 좋다더라 이런 얘기를 하면 자기가 모르는 게 있으면 괜히 그게 커보이고 해야될 것 같은 기분이 들죠? 그래서 지금 공부에 집중력이 떨어질 수가 있어요. 그렇기 때문에 여기 이 제품들은 정말 많은 오픈 소스들 중에 대표이고 일단 처음엔 여기에만 집중해도 충분하다는 것을 보여 드리려고 이렇게 선별과정을 보여 드린거에요.물론 이것도 적지않죠?그리고 강의 영상 마지막에 쿠버네티스 엔지니어가 되려면 이 많은 내용들을 어떻게 공부해야 되는지 이 그림으로 설명드릴께요. 쿠버네티스 기능으로 편해진 서비스 안정화 강의에서는 쿠버네티스가 편한 이유 중 두 번째로 기존 VM 환경과 쿠버네티스 환경의 차이를 얘기드려요. 기존 환경에서 여러 담당자들이 수동으로 설정해야 했던 일들을 쿠버네티스 환경에서는 쿠버네티스 엔지니어 한명이 한번에 할 수 있게 되거든요. 모니터링 설치이젠 모니터링 설치하는 방법도 너무 쉽죠?카페 설치 링크 (link)참고 링크 : grafana docs (link) / dashboard (link), prometheus install (link) / docs (link), loki-stack install (link) / docs (link)기능 실습그리고 강의영상에서 쿠버네티스 대표 기능들을 실습해 봅니다.카페 실습 링크 (link)인프라 환경 관리의 코드화마지막으로 쿠버네티스 관리 환경의 코드화인데, 인프라 설정을 수동으로 하는 거랑 파드에 인프라 설정이 코드로 들어가서 자동으로 되는 건 엄청난 차이고요. 이 차이가 인프라 환경 관리를 정말 편하게 해줍니다.쿠버네티스, 인프라 환경 관리의 장점인프라에 대한 History 관리가 편해짐인프라 작업 추적 가능인프라 환경별 파일 생성 (시간 있을 때 미리 구성 가능, 작업은 Copy & Paste)인프라 반복 작업 x, 퀄리티 향상에 집중새 인프라 작업시 이전 경험을 녹인 코드 활용블로그는 여기까지고 강의가 오픈 되면 링크 걸어 놓을게요^^굿나잇! ps. 매너가 좋아요♡를 만든다 :)

데브옵스 · 인프라･인프런･쿠버네티스･어나더클래스･지상편･일프로･kubernetes･devops･kubeops･container･쿠버네티스편한이유

Application 기능으로 이해하기-Configmap, Secret #7-2

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 : https://inf.run/NzKy전 처음 이 개념을 공부할 때, 책에서 설명을 읽으면서 "아 이거 알지", "이번 챕터는 거저 먹었네" 하고 챕터를 넘겼었거든요. App의 값을 넘겨주는 방법으로 환경변수를 사용하고 민감한 데이터일 경우, 암호화를 시켜서 파일에 담는 건 기존에 또 사용했던 방법이고 쿠버네티스의 Configmap과 Secret이 그 역할을 해준다는 거니깐요.근데 의외로 이 개념을 실무에서 쓰면서 목소리가 커질 일이 종종 생겼습니다일단 제가 처음 알았던 만큼만 설명을 드려볼게요 Configmap, Secret 개념 설명 Configmap과 Secret은 Pod에 바로 연결되고요. Object에 속성들을 보면 둘 다 데이터를 담을 수 있어요. 그래서 사용자가 데이터를 넣고 Pod에 값을 주입 시킬 수가 있는데, Pod에 연결되는 속성 이름을 보면 어떤 방식으로 들어가는지 알 수 있습니다.envFrom은 Pod안에 환경변수로 들어가게 하는 속성이고, 그래서 Configmap을 연결하고 Pod 안에 들어가서 env라는 명령을 쳐보면, 이 Configmap의 data가 주입 된 걸 볼 수가 있어요.Volume은 Pod와 특정 저장소를 연결하는 속성이고, Secret을 연결하고 Pod 안에 들어가서 마운팅 된 Path를 조회해보면, 이 Secret의 stringData가 있는 걸 볼 수가 있고요.특별히 어려운 내용은 없죠?아무리 처음 쿠버네티스를 공부하시는 분이더라도 환경변수와 마운팅의 개념은 기존에도 써왔기 때문에 쉽게 이해할 수 있어요. 그리고 Secret은 이름 부터가 뭔가 비밀스럽게 데이터를 처리해 줄 것 같은 느낌이 있으니까. 쿠버네티스에서 데이터에 어느 정도 보안을 적용해주는 가보다 생각할 수 있죠. Configmap 기능 설명Configmap의 데이터가 Pod에 환경변수로 들어간다고 얘기했는데, 환경변수에 들어가는 값은 다양하고요. Data에 내용을 보면 Key, Value 형식으로 spring-profiles-active에 dev가 있죠? 환경 변수로 흔히 들어가는 값인데, 인프라에 다양한 환경 개발/검증/운영 등에 환경이 있고, 이 App이 어느 환경에서 돌아가는 건지 App이 기동되는 시점에 알려주기 위한 변수에요.다음 환경변수에는 Application Role이라는게 있고. 말 그대로 이 App에 역할을 지정하는 건데, 예를 들어 한 App에 3가지 기능이 있는데, App 하나만 띄어서 모든 기능을 다 쓰기도 하고요. 스케일링 모드라고 해서 이 App을 기능별로 3개를 띄우고 부하가 많은 기능만 별도로 더 띄워요. 요즘은 마이크로 서비스 아케텍쳐를 반영해서 이렇게 만들어진 오픈소스도 많습니다.밑에 postgresql-filepath는 또 다른 예인데, 이건 여기 Secret 데이터로 연결할 파일에 경로에요. 이 경로는 Pod에 mountPath에서 정하거든요. 그리고 이 경로 DB 정보를 환경변수로 주면, App은 기동 될 때 이걸 읽어서 DB에 접속할 수 있도록 로직이 되있는데, 이 경로를 이렇게 환경변수로 입력해야 Pod에서 이 경로를 바꾸게 됐을 때 App을 다시 빌드해서 새 이미지를 만들지 않고, Configmap만 수정해서 App이 변경된 경로를 인식할 수 있도록 할 수 있겠죠?이렇게 외부에 변경되는 환경이 생길 때, 그걸 App에 전달해 주기 위한 값들도 있는거고, App 내부적으로 기동되는 시점에 이 환경변수 값에 따라 다르게 처리되는 로직이 있어야 되요.자 그럼 이제 이 내용을 Pod랑 연결을 하고 Pod가 생성됐을 때 상황을 얘기 해볼께요. 처음에 Configmap에 있는 data의 모든 내용이 컨테이너 내부 환경에 환경변수로 주입이 됩니다. 그리고 이 이미지를 만들 때 이런 자바파일 실행 명령을 넣어놨거든요. 이미지를 만드는건 sprint2에서 배울꺼고 이 명령이 컨테이너 생성 후에 자동으로 동작하게 되고, 이때 환경변수 값이 들어가는데, 만약에 환경변수로 spring-profiles-active가 없었다면 null값이 들어가게 되요. 밑에 Secret의 기능 설명과 두 기능에 대한 동작 확인은 강의 영상으로 설명 드리고요. Secret 기능 설명동작 확인영역 파괴의 주범 ConfigMap기존 VM환경이랑 쿠버네티스 환경의 배포 차이를 보면서 영역 파괴의 주범인 ConfigMap에 대한 얘기를 해볼께요. 각 환경마다 Pod가 만들어지고, 이 Pod에 들어가는 컨테이너는 dockerhub에서 모두 같은 이미지를 다운 받았어요. 하지만 환경마다 다른 값을 주려고 각각에 Configmap을 만들죠. 그리고 이미지 안에 변수값을 받아서 실행하는 명령어가 들어 있어요.이제 개발환경을 보면 이렇게 spring으로 개발을 하고 여기서 [개발자]가 Properties 파일들이 만들고 관리를 해요. 그리고 Github로 소스를 커밋하면, 여기서부터는 [데브옵스 엔지니어]가 Jenkins에서 이 소스를 받아서 파이프라인을 구성하는데, 소스 빌드와 컨테이너 빌드 과정에서 컨테이너 이미지가 도커 허브로 올라가요. 그리고 컨테이너 빌드 후에 개발환경을 바로 이어서 배포를 할 수 있고, qa와 prod는 필요할 때 배포 버튼을 따로 누르게 구성해 놨다고 해보겠습니다.그럼 VM 환경의 배포는 어떤지 보겠습니다.개발 환경과 CI/CD 환경은 비슷하고, [인프라 담당자]가 환경별로 서버를 세팅해 놓습니다. 각 환경별로 OpenJDK도 설치해 놓고요. 이 과정에서 VM 내부에서 사용할 환경변수들을 관리를 하죠. 그리고 배포는 이렇게 되는데, Jar 패키지 파일을 VM 환경에 복사 해놓고, 실행 명령을 직접 날리는데 이때 [데브옵스 관리자]이 App에 환경이나 목적에 맞는 변수를 넣어요. 그리고 환경이나 목적에 맞게 변수값이 채워진 스크립트를 실행시킵니다.그래서 여기까지 보면 쿠버네티스 환경 이전에는 각자의 영역에서 담당자들이 관리하는 환경변수들이 있었는데, 쿠버네티스가 나오고 이 ConfigMap에서 모든 역할을 다 할 수가 있게 된 거죠. 그래서 ConfigMap을 담당하는 사람이 다른 영역을 넘나들 수 있게 되고 이런 소지를 주는 Configmap을 좀 과격한 표현으로 영역 파괴의 주범이라고 표현을 한 건데.물론 이 전체를 혼자 다하는 슈퍼 개발자도 있겠지만, 프로젝트가 클 수록 각 영역에 담당자들이 있고요. 현재 이 모두가 쿠버네티스를 다 다룰 줄 아는게 아니기 때문에 만약 개발자가 쿠버네티스를 잘하면, 이 Properties 값들 중에 Pod를 재생성하기만 하면, 다시 빌드하지 않고 바로 반영될 수 있는 값들을 많이 집어넣겠죠? 그러다가 다른 영역에 있는 값들도 넣으면서 일을 주도하게 될꺼예요.하지만 다른 담당자 입장에서는 본인의 영역을 침범 당한다고 생각할 수 있는데, 참 별거 아닌 기능이지만, 여러 영역에 걸쳐 있는 기능이기 때문에 의견을 잘 조율을 해서 써야 되는 점 주의하시길 바랄께요. 이름 때문에 기대가 너무 컸던 Secret이 부분은 강의 영상을 확인해 주시고, 강의에서 만나요! ps. 좋아요♡는 준 만큼 받는다 :)

데브옵스 · 인프라･인프런･쿠버네티스･어나더클래스･지상편･일프로･kubernetes･devops･kubeops･Configmap･Secret

[쿠어클#4] 쿠버네티스 무게감 있게 설치하기

안녕하세요. 쿠버네티스 제대로 시작하기 첫 강의로 쿠버네티스 환경 구축을 해보겠습니다.아래 정말 쉽고 빠르게 쿠버네티스를 설치하는 방법이 있어요! 쿠버네티스(v.1.27.2) 쉽고 빠르게 설치하는 방법Virtualbox 설치 (link)Vagrant 설치 (link)Vagrant 스크립트 실행 (윈도우 > 실행 > cmd > 확인)# Vagrant 폴더 생성 C:\Users\사용자> mkdir k8s C:\Users\사용자> cd k8s # Vagrant 스크립트 다운로드 C:\Users\사용자\k8s> curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/vagrant-2.3.4/Vagrantfile # Rocky Linux Repo 세팅 C:\Users\사용자\k8s> curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/vagrant-2.3.4/rockylinux-repo.json C:\Users\사용자\k8s> vagrant box add rockylinux-repo.json # Vagrant Disk 설정 Plugin 설치 C:\Users\사용자\k8s> vagrant plugin install vagrant-disksize # Vagrant 실행 (VM생성) C:\Users\사용자\k8s> vagrant upMobaXterm 설치 (link)Master 원격 접속 : 192.168.56.30:22 (root/vagrant)Pod 확인kubectl get pods -A대시보드 접속 URI : https://192.168.56.30:30000/#/login FAQ : virtualbox 설치 안될 때 (link), vagrant up 안될 때 (link), dashboard 관련 (link), virtualbox Host-Only Network cidr 변경 (link)Cafe : 쿠버네티스 빠른 설치 카페 참조 (link) 정말 쉽죠?하지만 저는 쿠버네티스 설치를 쉽고 빠르게 한다고 해서 좋은 건 아니라고 생각합니다. 쿠버네티스 오브젝트들, Pod나 Service를 공부하면서 개념이나 기능만으로 이 기술을 이해하는데는 한계가 있거든요. 쿠버네티스 자체 구성을 조금은 알고 이 개념들을 공부하는게 더 잘 이해가 잘 되요. 그리고 쿠버네티스 구성에 대한 부분들은 쿠버네티스를 설치할 때 가장 배우기 좋은 내용입니다.그렇기 때문에 Pod를 빨리 만들어보고 싶은 마음도 이해하지만 쿠버네티스를 제대로 공부하고 싶으신 분이시라면, 이번 설치 강의를 통해서 쿠버네티스 구성을 꼭 이해하고 넘어가길 권해드려요. 아니 꼭 이렇게 하셔야되요! 쿠버네티스 무게감 있게 설치하는 방법 1/2먼저 설명에 시작은 내 PC에 Virtaulbox랑 Vagrant를 설치한 상태고요. 제가 만든 Vagrant 설치 스크립트를 받으면 위에 내용이 나와요. 그리고 이 스크립트는 크게 [Virtualbox로 Rocky Linux를 생성]하는 파트랑 [kubernetes를 설치]하는 파트로 구분되는데 먼저 Virtualbox로 VM을 생성하는 걸 설명 드릴께요. 우측 스크립트를 위에서 부터 보면, OS를 [rocky linux 8]버전으로 설치하라는 내용이고, 처음 설치할 때는 이 이미지를 다운 받는데 시간이 좀 걸려요. 그리고 [master-node]는 Virtualbox 입장에서 생성된 VM에 이름을 붙여주는 부분인데, Virtualbox UI 상으로 봤을 때 보이는 이름 이예요. 그리고 밑에 hostname 을 지정하는 부분이 있고, [k8s-master] 라고 넣으면, 나중에 원격접속으로, 리눅스에 들어 갔을 때, 나오는 호스트 이름입니다. 그리고 밑에 [private_network]는 virtualbox에 Host-Only Network 라고 해서, 내 PC 에서만 사용할 수 있는 네트워크망을 만들어 주고, 스크립트에서 IP를 주면 내 Linux에 그 IP가 할당됩니다. 그래서 우리는 내 PC에서 이 IP로 원격 접속을 하면 Linux OS에 들어갈 수 있게 되는 거고. 브라우저를 통해서 kubernetes dashboard에 접속 할 수도 있게 되요. 이렇게 이 스크립트 한 줄로 Host-Only Network가 만들어지고 IP가 할당 되는데, 스크립트에 넣지 않아도 Vagrant가 기본적으로 만들어주는 네트워크가 있어요.바로 NAT 라는 네트워크고 입니다. IP도 알아서 할당 돼요. 이 NAT의 역할은 내 VM을 외부 인터넷이랑 연결 시켜줍니다. 그래서 이따가 쿠버네티스를 설치할 때 필요한 패키지들을 받는데 사용하고요 실제 내 PC에 할당된 Network는 공유기에서 할당 받은 상태죠. 제 PC의 경우 [192.168.219.100]의 주소를 할당 받았고요. 제 공유기는 192.168.219까지는 고정이고, 뒤에 4번째 자리는 1~255까지 만들 수 있는데 자동으로 100이 할당 된 거예요.근데 Host-Only Network를 보면 디폴트로 192.168.56까지 고정이고, 네 번째는 1~255까지 만들 수 있는 네트워크 입니다.네트워크를 생성할 때 cidr 을 정하면, 이렇게 지정한 범위 내에서 IP가 할당 되는데, 네트워크 원리는 잘 몰라도, 최소한 대역들이 겹치면 안된다는 건 알고 계셔야 돼요. 겹치게 되면 내 공유기랑 Virtualbox가 똑같은 IP 를 만들 수 있게 돼서 IP 충돌이 나요. 근데 이 공유기 환경이 개인 마다 다른 부분이라서 혹시 원격 접속이 안되시는 분은 본인에 Network 대역을 확인해 보시고요. 부득이한 경우 Host-Only Network에 cidr 을 수정해 주면 돼요. 제가 카페에 방법을 올려 놓을께요. 여기까지 네트워크에 대한 설명이 이었습니다.이번엔 자원(resource)을 볼께요.스크립트를 보면 VM에는 Memory는 4G고 CPU는 4Core를 잡았어요. 제 PC에 자원을 보면 제 PC는 4Core, 16G Memory거든요. 여기서 분명 Memroy는 내 자원에서 나눠 주는 거라 VM에 자원 할당한 게 이해 되는데, CPU를 이렇게 다 줘버리면 내 PC는 괜찮을까 걱정되는 분이 계실 거예요.근데 이 두 자원의 속성을 보면 Memory는 서로 할당된 공간을 침범하면 안돼요. A프로그램이 쓴 메모리 공간에 B프로그램이 침범해서 내용을 바꿔버리면 안되잖아요? 그래서 꼭 자원을 철저하게 분할해서 써야 되는 성격이라면, CPU는 필요로 하는 순간에 서로 나눠 쓰는 자원이예요. 그래서 현재 이 CPU 할당에 의미는 내 PC CPU가 필요할 때는 4 Core를 다 쓸 수도 있고. VM에서도 필요할 때도 최대 4Core를 다 쓸 수 있도록 설정 한 건데, 만약 둘 다 CPU가 필요한 상황이라면 이 4core 자원을 나눠쓰고요. 대신 처리속도는 좀 느려지지만 문제는 없어요.참고로 쿠버네티스 설치 문서에 권고하는 CPU는 2Core 이상입니다.이 CPU와 Memory에 대해서 제가 4 Core를 준 이유와 각자가 작업 유형에 맞게 변경을 하시라고 자세히 설명 드렸지만, 이 두 자원에 대한 성격은 쿠버네티스에도 Pod에 자원을 할당하거나 Pod가 늘어나는 설정을 할 때, 정말 중요하게 고려해야 되는 포인트라서 이 자원에 성격을 자세히 얘기 해봤어요. 쿠버네티스 무게감 있게 설치하는 방법 1/2 [구간별상태확인]카페(아직 공사중)에 들어가보면 각 포인트에 대해서 잘 설치됐는지 확인 볼 수 있어요. (link) 쿠버네티스 무게감 있게 설치하는 방법 2/2위 내용은 강의의 메인으로 쿠버네티스 설치인데 강의에서 자세히 설명 드립니다. 지금까지 설명 드린 강도랑 내용보다 좀 더 깊어지는 점 주의 드려요.쿠버네티스 설치는 확실히 쿠버네티스 문서(link)를 보는게 좋습니다. 내가 설치하려는 버전이 있는데 블로그에서 다른 버전이나 최신버전 설치를 보게 되면, 미묘하게 잘 안되는 부분들이 생기거든요. 그래서 그 원인을 찾는데 시간을 더 쓰는 경우도 생기는데, 쿠버네티스는 컨테이너 한방 정리에서 히스토리로 봤듯이 내부적인 변경사항들이 많아서 그래요. 그래서 쿠버네티스 문서에서 필요한 버전별로 설치 가이드를 보는 게 좋고 쿠버네티스 문서가 한글화도 잘 되있거든요. 전 이 한글화 된 문서를 정말 열심히 보고 있고 이 한글화 작업하시는 분들께 항상 감사 드리는 마음입니다. 이 강의 설명의 목적은 쿠버네티스 설치 문서를 함께 공부하면서, 수강생 분들이 이 강의를 잘 들으면 이 강의에 설치 뿐만 아니라 다른 버전으로 쿠버네티스를 설치하거나 컨테이너 런타임을 바꿔보고 싶을 때 스스로 찾아서 할 수 있는 능력을 길러 드리는 거예요. 쿠버네티스 무게감 있게 설치하는 방법 2/2 [구간별상태확인]마찬가지로 카페(아직 공사중)에 들어가보면 각 포인트에 대해서 잘 설치됐는지 확인 볼 수 있어요 (link) 나중에 다른 사람과 똑같이 쉽게 쿠버네티스를 설치하더라도 이렇게 공부하면 한번에 클릭이 좀 더 무게감 있는 사람이 됩니다. 가끔 보면 그냥 빨리빨리 버튼 누르고 진행할 수 있는 상황에도 버튼 하나 누를때마다 한참 생각했다가 누르는 사람이 주변에 있지 않나요? 그 사람이 아는 게 많을 수록 이 버튼 누르는 속도는 더 느려져요. 이 사람은 겉으로는 답답해 보일 수 있는데, 머릿속에는 엄청 많은 정보들이 스쳐 지나가고 있는 겁니다.여러분도 이렇게 되시길 응원 드려요! 그럼 이번 블로그는 여기까지고요, 해당 강의에서는 실습과 더불어 추가적으로 아래 내용들에 대해서 더 다룹니다 😀[쿠버네티스 어나더 클래스] : https://inf.run/unreT 좋아요 ♡는 저에게 큰 힘이 됩니다 :)

데브옵스 · 인프라･인프런･쿠버네티스･어나더클래스･지상편･일프로･kubernetes･devops･kubeops･container･쿠버네티스설치

[kubernetes] 강의 소개 #1

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요! 강의 링크 : https://inf.run/NzKy 제가 이전 쿠버네티스 강의를 만든 지 벌써 4년 정도가 지났는데, 그동안 저는 현업에서 계속 프로젝트를 하느라 바쁘게 지내고 있었어요. 최근 여유가 생겨서 이렇게 다시 강의 만들 기회를 가질 수 있게 됐고, 제일 먼저, 어떤 강의를 만들지 고민을 많이 했습니다.쿠버네티스가 나온 지 적지 않은 시간이 지났고, 인터넷이나 많은 책들을 통해서 필요한 내용을 쉽게 찾아볼 수 있게 됐죠. 그리고 그 내용들을 보면 이제 정말 쿠버네티스를 잘 아는 사람들이 많아 졌구나를 느끼는데 막상 프로젝트를 하다보면 주변에 쿠버네티스를 생소하게 생각하는 분들이 아직도 훨씬 많습니다.그리고 시도를 했다가 포기를 하시는 분들도 더러 봤는데 정보는 많지만 여전히 쿠버네티스가 새로 시작하는 사람들에게 큰 진입 장벽이 있는 것 같아요.그래서 저는 기존보다 더 난이도 있는 강의를 만드는 것보다 입문자가 더 쉽고 재미있게 쿠버네티스를 시작할 수 있는 강의를 만드는 게 더 의미 있는 일이라고 생각을 했고, 처음엔 저도 쿠버네티스를 시작하면서 새로운 개념들을 이해한 다음 다 중요하고 써먹어야 할 것 같아서 프로젝트에 적용을 했다가 다시 걷어내는 일들을 반복을 했는데 이건 쿠버네티스 기술이 워낙에 광범위하기 때문에 누구나 겪게 되는 문제이자 반면에 쿠버네티스를 포기하게 만드는 원인인 것 같아요.전 이제 그동안의 경험으로 어떤게 중요하고, 어떤 건 적당히만 알면 되고, 또 어떤 건 잘 안 써서 몰라도 되는 건지에 대한 감이 좀 생겼는데, 이 강의는 기존 A~Z식의 얇고 넓은 범위의 강의가 아닌 하나를 공부를 하더라도 그 개념에 대한 배경 지식을 충분히 이해하고 깊이 있는 실력을 만들어 주는 강의를 만들어 보려고 해요.그래서 강의 제목에 이전 강의와는 또 다른 방식의 강의라는 의미로 어나더 클래스라는 이름을 붙여 봤습니다. 강의 주제먼저 강의 주제로 전체적인 제 강의의 컨셉을 설명 드리면, 쿠버네티스 어나더 클래스는 총 3개의 Sprint로 나눠져 있고 각각의 Sprint는 다른 주제를 가지고, 새 강의로 만들어져요.그래서 결국 모든 강의를 다 들으시려면 세 번의 수강 신청을 하셔야 하는 건데, 이렇게 나누는 이유는 앞에서도 말씀드렸다시피 이제 쿠버네티스를 어느 정도 잘 아는 분들이 많아졌기 때문에 제 강의에서 필요한 부분만 듣고 싶은 분들도 분명히 계실 거예요. 그래서 강의 설명을 잘 보시고 내가 필요한 내용 인지를 판단해서 조금이라도 낮은 가격으로 필요한 내용을 수강할 수 있게 하기 위해서 입니다.저도 각 강의에 어떤 내용들이 담겨져 있는지에 대해서 최대한 알려 드리도록 노력을 할게요. 그리고 Sprint가 보통 2주를 얘기를 하는데 여러분들이 Sprint 강의 하나를 들을 때 최소 2주는 잡고 공부를 했으면 해요. 5시간 정도의 강의 분량을 2주 동안 듣는 방법은 바로 복습을 해야 된다는 거구요. 강의 내용 중에도 제가 계속 복습을 강조를 할 건데 그 방법에 대해서는 강의를 통해서 더 말씀을 드릴게요.그리고 Sprint마다 이름이 있어요. 모두 북극에 사는 귀여운 동물들인데 사실 제 입장에서는 이 Sprint 하나를 제작하는데 두 달에서 세 달 정도 걸리는 소규모 프로젝트거든요. 그래서 제가 강의 하나하나에 의미를 부여하기 위해서 이렇게 이름을 지어 봤습니다. 현재 여러분께서는 Sprint1의 Polar Rabbit의 강의 소개를 보고 계십니다.다음으로 이 강의에 수강 대상이 좀 많죠? 절대로 아무 생각 없이 제가 아는 IT직군을 모두 때려 넣은 건 아니구요. 이 분들이 수강을 하셔야 되는 이유는 뒤에서 별도로 말씀을 드릴 건데, 일단 대상군이 많다는 건 입문자가 들을 수 있는 난이도 라고 보시면 되고, 이 세 개의 Sprint 전체가 그렇고 저는 이 전체에 대한 난이도를 [지상편]이라고 붙였습니다. 그럼 이제 다음편으로 조금 더 높은 수준의 난이도가 있겠죠? 점점 깊게 들어가는 의미로 [해수편]과 [심해편] 그리고 [해연편]까지 생각을 하고 있구요. 각각에 수강 대상은 다른데, 저는 최근까지 큰 프로젝트에서 쿠버네티스 파트에 아키텍트 역할을 해왔고요. 최대한 제가 했던 일까지 모두 강의로 만드는 게 최종 목표입니다. 강의 소개이제 수강 대상과 이 대상들이 쿠버네티스를 왜 알아야 되는지 얘기를 해볼게요. 채용 우대사항에 항목들은 점점 많아지고 있습니다. 이 우대사항은 그 팀에서 주로 쓰는 개발환경을 나열해 놓기 마련인데, 그만큼 IT시스템이 나날이 복잡해지고 있다는 거죠. 그리고 여기에 쿠버네티스가 직군을 막론하고 한 자리를 차지하고 있는 걸 볼 수 있고요. 그래서 이젠 구직할 때 쿠버네티스도 알아야 하는데, 우대사항까지 이렇게 챙겨야 되나 싶겠지만, 요즘은 고스펙 경쟁 시대라 구직자 분들께 부담을 드리는 것 같아 죄송하지만 어느정도는 알아야 한다고 말씀드릴께요. 이들에게는 각자의 영역이 있지만 쿠버네티스는 어느 특정 영역에 한정되지 않아요. IT 전체에 퍼져서 매력적인 기능들을 제공하고 있는데요. 그래서 개발자가 쿠버네티스에 한번 발 담구다 보면 어느새 인프라의 스토리지를 밤새 공부하고 있는 자신을 발견하기도 합니다.그래서 저는 쿠버네티스가 영역 파괴자라고 불러도 과언이 아니라고 생각하고 각 영역에 대한 경계를 많이 모호해지게 만들었다고 보는데, 그만큼 쿠버네티스를 잘 모르면 누군가에 의해서 내 영역이 흔들릴 수가 있게 된다는 거죠. 그래서 쿠버네티스를 더 잘 알아야 각자의 입지를 더 튼튼하게 다질 수 있다고 말씀드리고요.기존 환경을 쿠버네티스 환경으로 전환하는 큰 프로젝트들이 많아지고 있고, 물론 쿠버네티스 환경이 구축되면 장애에 대해 좀 더 여유가 생기는 건 사실이지만, Container나 Pod 등 새로운 용어나 기술사용 들이 기존 시스템과 많이 다르긴 합니다.그렇기 때문에 이런 새로운 환경을 갑자기 받아들이는데 부담이 있을 수 밖에 없어요. 근데 구축팀 입장에서 프로젝트 오픈에 허덕이다 보면 중간중간 운영팀에 교육을 하기 힘든 경우가 많은데, 이때 운영팀에 팀원들은 이 시스템을 받는 것에 대한 걱정이 많아지면서 조금씩 이직에 대한 고민을 합니다. 하지만 이직은 선택을 지연시킬 뿐이예요. 어차피 쿠버네티스 환경은 계속 많아질 것이기 때문에 나중에 또 같은 상황으로 이직을 고민하게 될 수 있습니다.그래서 가장 좋은 건 부담이 생기기 전에 미리미리 쿠버네티스를 공부해 놓고, 프로젝트가 진행되는 걸 편하게 지켜보면서 내 입맛에 맞는 요구사항들을 쏟아내는 거겠죠? 이미 쿠버네티스를 도입해서 비용을 절감했다는 입소문이 퍼지기 시작했고, 너도나도 쿠버네티스를 적용해보려는 시도들이 많아 졌습니다. 근데 자사에 운영 인력이 부족한 기업에 경우 솔루션 업체에 도움을 구해야 되는데, 문제는 솔루션 업체들도 현재 인력이 많이 없는 상황이예요. 그래서 쿠버네티스 전문 인력을 새로 뽑으려는 업체도 많고요.분명 기존 솔루션 엔지니어 분들은 회사에서 쿠버네티스를 공부하라는 압박이 있을 거에요. 이때 억지로 떠밀려서 공부하면 정말 재미가 없는데, 앞으로 또 10년 더 직장생활이라는 안정적인 먹거리를 위해서 지금 한번 고생을 해본다는 마음을 먹으시길 바라고, 몇년이 지난 후에는 이때의 선택을 잘했다고 생각하게 될 날이 분명히 올 겁니다. 쿠버네티스를 선택하면 따라오는 오픈소스들이 너무 많아요. 그리고 이 오픈소스들은 각각에 장단점이 있는데, 그 장단점이 대중적으로 정해졌다기 보단, 프로젝트 규모와 상황, 그리고 쓰는 사람들의 수준에 따라 다르거든요. 그래서 쿠버네티스 담당자는 제안서를 쓸 때부터 오픈을 할 때 까지 내가 이 오픈소스를 잘 선택한건지 계속 의문을 품게 되요.정답은 없고, 이 프로젝트에서 이게 가장 효율적인 선택이었다라는 평가를 해줘야하는데, 그걸 최종적으로 해 주는 사람이 바로 PM/PL입니다. 새로운 기술에는 항상 반발이 있기 때문에 이분들이 기둥을 잘 잡아줘야 되요.그래서 리더는 프로젝트를 하는 동안 담당자 얘기를 계속 경청하고 의견을 줘야겠지만, 최소한 누군가의 말에 휘둘리지 않는 정도의 지식은 있어야 겠죠? 강의 특징먼저 이 강의를 위해서 네이버 카페(링크)를 만들었는데, 용도는 첫 번째로 강의 자료실 입니다. 앞에서 설명 드렸다시피 제 강의는 여러 Sprint로 나눠져서 만들 예정이라 이렇게 카페가 중심이 되서 저는 자료들을 통합적으로 관리 할거구요. 그러면 여러분들도 이 한곳에서 필요한 정보를 빠르게 캐치할 수 있게 되실 거예요.두번째로, 여러분들의 복습 진도를 체크하려고 하는 건데 이 부분은 강의 중에 별도로 영상을 만들었으니까 수강 후에 보시기 바랍니다. 그리고 이 강의가 어떤 느낌의 강의인지는 강의 중간중간을 편집한 영상을 유튜브(링크)에 올려놨는데, 직접 보고 판단하시길 바랄게요. 제가 앞에서 어떤 강의를 만들어야겠다는 목표를 얘기를 했지만 영상 제작과 교육 기법에 대한 부분은 또 별개인 것 같아요. 그리고 저는 전문 강사는 아니기 때문에 그런 부분들은 직접 보시고 내가 수강하기에 편한 형태인지는 직접 판단을 해 보세요.참고로 저는 이전에 만든 강의에서 들었던 단점을 보완하려고 노력을 했고, 인프런의 전체 강의의 별점이 1~2점인 수강평들을 쭉 보면서 나는 이런 실수는 하지 말아야지에 대해서 집중을 했습니다. 근데 제가 얼굴을 띄워 놓고 영상 강의를 하는 건 또 처음이라 표정이 좀 어색하더라도 이해를 부탁 드릴게요. 앞으로 점점 부드러워지지 않을까 싶어요 :) 학습 내용[강의설명]에 이렇게 강의에 대한 주요 이미지들을 올려놨기 때문에 어떤 내용을 다루는 건지 알 수가 있어요! 만약 위 그림들로 부족하면 제가 강의를 만들면서 블로그(link)로 강의의 일부 내용을 올려놨습니다. 이 내용들을 보시고 충분히 판단을 한 다음에 강의를 수강 하세요. 실습 환경지상편 전체 실습 환경으로 개발 환경과 CI/CD 환경 그리고 인프라 환경을 구성할건데, 각 Sprint 마다 하나씩 구성이 될 예정이에요. 그래서 Sprint1 에서는 인프라 환경만 구성을 해서 실습이 진행된다고 보면 됩니다. 최종적으로는 이 전체 환경을 직접 구성하고 활용할 수 있게 되는데, 이게 컨테이너 환경의 전체 파이프라인 입니다. [지상편]을 모두 잘 수강하면 이 내용들이 모두 내 PC위에서 돌아간다고 보시면 돼요. 이 흐름에 대한 내용은 강의 중에서 자세히 설명을 드릴께요.그래서 현재 Sprint1 에서는 이런 환경을 구성할 건데, 내 PC에 VirtualBox와 Vagrant를 이용해서 Guest OS를 띄우고 설치 스크립트로 인프라 환경을 쭉 만듭니다. 그리고 쿠버네티스를 다룰 때는 원격 접속 툴을 이용해서 서버에 들어가면 kubectl이라는 툴이 있고, 이걸로 쿠버네티스 명령을 날리면서 실습을 하고 브라우저로 대시보드에 접속을 해서 쿠버네티스를 조작하기도 해요. 학습 자료는 인프런에 기본 수업자료를 다운받는 곳을 보면 PDF로 제공을 하고 있어요. 그리고 수강평을 작성하신 분에 한에서 강의 자료실에서 원본 PPT를 받을 수 있으니까, 필요하신 분께서는 (링크)로 들어가서 방법을 읽어보세요. 그럼 여기까지 강의 소개를 마치며,이 강의가 여러분께 쿠버네티스를 쉽고 재미있게 시작하는데 도움이 됐으면 좋겠습니다.

데브옵스 · 인프라･인프런･쿠버네티스･어나더클래스･지상편･일프로･kubernetes･devops･kubeops･container･강의소개

[쿠어클#7-1] Application 기능으로 이해하기-Pod (probe)

쿠버네티스를 공부 하다보면 경계를 해야 되는 상황이 있어요. 내가 어떤 개념을 힘들게 공부하고 사용법을 익혔을 때, 그 기능을 내가 하는 프로젝트에 적용 시키고 싶은 마음이 생기죠?여기까진 좋은데.그 기능을 적용함으로써 "운영에 불편한 관리 요소가 생기진 않을지?", "오히려 시스템에 복잡도만 증가 시키는 건 아닐지?" 는 충분히 고민하지 않는 경우가 있습니다.예를 들어, 쿠버네티스에는 NetworkPolicy 라는 object가 있는데, 쉽게 말해 Pod들 간에 방화벽 역할을 하는 는 기능 이예요. 보통 큰 프로젝트 환경을 보면 별도로 보안을 담당하는 사람이 있고, 내부 시스템을 외부에서 연결할 수 있도록 하거나 시스템 간에 통신을 해야 할 때 이 담당자한테 방화벽 오픈 신청을 먼저 하죠. 이렇게 전체적인 시스템에 대해서 방화벽이 관리되고 있는데, 쿠버네티스 클러스터 안에 NetworkPolicy를 적용하고 별도에 내부 방화벽 정책을 또 사용 할지에 대해서는 꼭 그렇게 해야 되는 이유를 충분히 고민 해봐야돼요.근데 오늘 배울 이 쿠버네티스의 기능은 백퍼센트 사용을 해야되지만 내 Application에 대한 충분한 이해가 없으면 생각지도 못한 장애를 만날 수가 있습니다.바로 Pod에 probe라는 기능인데요.실제로 저도 Pod가 내가 의도하지 않은 상황에서 죽었을 때, 원인을 분석하다 보면 이 기능을 잘못 사용해서 그랬던 적이 있을 만큼 정확하게 이해하고 적용 시켜야 되는 기술입니다. Pod (probe) - 프로브 기본 개념 3가지 종류가 있고 모두 /ready라는 url을 8080포트에 10초 간격으로 날리는데, 각각 성공이랑 실패에 대한 수치는 위 그림처럼 되어 있다고 해볼게요.컨테이너 안에 있는 App에서는 /ready라는 url이 사전에 만들어져 있어야 되고 Pod가 만들어지자마자 이 probe 기능들은 동작합니다.App은 처음 기동 중인 상태가 있고, 이때 쿠버네티스가 startupProbe 기능을 동작 시키면서 오브젝트 속성에 있는 대로 10초에 한 번씩 /ready라는 api를 App에 날려요. 기동 중일 때는 응답을 받을 수 없으니까 계속 실패가 될꺼고 10번 실패하기 전에 한번이라도 응답이 오면 성공으로 간주합니다. startupProbe 가 성공하면, 쿠버네티스는 startupProbe 기능을 중지 시키고 livenessProbe랑 readinessProbe기능을 동작 시킵니다. 그리고 또 설정 한대로 두 probe는 /ready라는 api를 10초 간격으로 반복해서 날리는데 App이 살아있는 동안에는 계속 200 OK 결과를 리턴 해주면서 이 두 probe 동작은 반복됩니다.각각의 역할은 다른데요.readinessProbe는 성공했을 때 외부 트래픽을 Pod가 받을 수 있는 상태로 만들어 주면서 서비스가 활성화 되고요. livenessProbe는 app이 살아 있는지를 계속 체크하는 역할 이예요. livenessProbe는 만약 App에 장애가 발생하게 되면, API는 실패를 하게 되고 설정에 따라 두 번을 실패하게 되면 쿠버네티스는 App을 재기동 시킵니다.이게 쿠버네티스에 프로브에 대한 기능이고, 일반적으로 자신에 App 기동 시간에 따라 startupProbe에 실패 횟수만 조정해서 쓰는 게 대부분인데 처음엔 이렇게 쓰더라도 어느 순간 이런 생각이 들 때가 있을 거예요. "왜 probe 마다 귀찮게 api들을 기입하는 항목이 각각 있을까?" 어차피 모두 같은 url을 지정해서 쓰는데, 그리고 또 한가지가 "어차피 장애가 나면 livenessProbe랑 readinessProbe는 같이 실패를 할 텐데, 굳이 readinessProbe도 계속 호출될 필요가 있을까?"쿠버네티스가 괜히 이렇게 해놓지는 않았을 텐데 "혹시 내가 이 프로브들을 제대로 쓰고 있는 게 아닌가?"이 프로브들을 간단하게만 써도 나쁘진 않지만 오늘은 이런 의문이 생기는 사람들을 위해서 probe에 대해서 좀 더 깊게 공부를 해보겠습니다. Pod (probe) - 실습카페 자료실 링크 (link)강의 영상에서는 실습이 함께 진행됩니다. Pod (probe) - 실습 로그 분석이제부터 실습 후 로그를 함께 분석해 볼게요. 먼저 App이 초기화 되기 시작했고, Spring이랑 Servlet을 초기화 과정이 있어요. 다음으로 Database를 연결하는데 실제 DB가 있는 건 아니고 그냥 제가 코드에 로그만 찍어 놓은거예요. 그리고 이렇게 App이 기동되는 동안 startupProbe는 계속 실패하고요. startupProbe가 찍히는 주기는 설정 해놓은대로 5초 간격이죠. 그리고 기동이 완료되면 startupProbe는 성공을 합니다. 근데 이 로그들은 startupProbe가 찍히는 걸 보여드리기 위해서 제가 임의로 코드를 구성했기 때문에 로그가 보이는 거예요. 무슨 말이냐면, 실제 App 상황에서는 쿠버네티스는 Pod가 생성되자마자 startupProbe를 작동 시키기 때문에 사실 처음부터 API는 실패 되고 있었거든요.이렇게 App이 기동 되기 전에는 API를 받지 못하기 때문에 실제로는 startupProbe에 로그가 찍힐 수가 없고, 만약에 Was로 tomcat을 썼다면 startupprobe가 찍히는 건 access.log 에서만 볼 수 있게 돼요.그래서 이 로그는 제가 임의로 코드를 구성한 학습적인 상황이라고 말씀드리는 거고요. 이제 기동이 완료가 됐고, [ConfigMap data is loading]은 사용자가 App이 기동 된 후에 외부에 데이터를 가져와서 추가적으로 시스템을 초기화 시키려는 상황 이예요. 그리고 밑에 livenessProbe랑 readinessProbe도 찍히기 시작했고요. 이때 readinessProbe는 실패했고, livenessProbe만 성공을 했네요. 그리고 추가적인 데이터 작업은 끝났고요.그림 제일 하단에 livenessProbe랑 readinessProbe는 계속 찍히고 있는데, 이제 둘 다 성공을 했네요. 그리고 호출 주기는 10초고요.근데 여기 보면 readinessProbe가 한번 실패를 했죠?이건 사용자 초기화 구간에는 readinessProbe가 실패 하도록 일부러 만든 거예요. 그래서 의도 한대로 현재 기능이 정확하게 동작을 해준 건데, 일단 이런 사실만 기억하고 다음으로 넘어가서 강의 영상에서 Application 동작 중심에 프로브를 다시한 번 설명 드립니다. 밑에 내용들을 강의 영상에서 설명 드릴 내용들 입니다. Pod (probe) - Application 동작 중심의 프로브 이해해당 내용은 근본적으로 쿠버네티스에서 왜 프로브라는 기능이 생겼는지 생각해봅니다.Pod (probe) - API 날려보며 프로브 동작 확인하기그리고 API를 날려보면서 앞에 설명한 기능들을 확인해보고요. Pod (probe) - 일시적 장애 상황에서의 프로브 활용마지막으로 일시적인 장애 상황에서 프로브를 좀 더 활용하는 방법을 얘기 해볼께요. 이렇게 강의를 모두 들으면 앞으로는 쿠버네티스에 프로브를 보게 될 때,내 app을 주의 깊게 관찰하게 되면서 어떻게 프로브를 잘 적용 시킬지 심각한 고민에 빠질 수 있게 되는 점 주의 바라며오늘 블로그는 여기까지 마치겠습니다. 해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다.강의 링크 : https://inf.run/NzKyps. 한번도 좋아요♡를 안 준 사람은 있어도, 한번만 좋아요♡를 준 사람은 없다. 당신은 어떤 사람인가요? :)

데브옵스 · 인프라･인프런･쿠버네티스･어나더클래스･지상편･일프로･kubernetes･devops･kubeops･Application기능으로이해하기･Pod(probe)

[kubernetes] 데브옵스 한방정리 #8

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 : https://inf.run/NzKy 이번 블로그에서는 아래 DevOps를 구성하는 오픈소스들이라는 주제로 데브옵스를 설명을 드립니다. 내용의 수준은 비전공자가 데브옵스에 대한 전반적인 내용을 이해하기 좋은 정도인 점 참고 바래요.데브옵스를 구성하는 오픈소스들DevOps가 개발에서 운영까지 원할한 흐름을 만드는 건데, 중간에 가장 중요한 역할을 하는게 CI/CD죠. CI는 통합된 소스를 가지고 빌드/테스트를 자동화 시키는 기능을 만드는 거고, CD는 배포를 자동화 시키는 기능을 만드는 거예요.그래서 결국 개발을 해서 커밋을 하는 순간, 운영 환경에 App이 자동으로 배포가 되는 파이프라인이 만들어 지는데, 세부적으로 나누면 위 그림처럼 8가지 단계가 있습니다.계획/개발, 빌드/테스트, 릴리즈/배포, 그리고 운영/모니터링 인데, 이걸 각 단계를 대표적으로 사용하는 오픈소스를 가지고 얘기를 해보겠습니다.[계획] 단계부터 시작 할께요.제가 개발할 당시에는 redmine을 많이 쓰긴 했는데, 지금은 Jira나 notion을 많이 써요. 기능은 비슷한데, UI가 요즘 스타일로 많이 세련되 졌고요. 개발 일정을 공유하거나 이슈 사항들을 기록해야 되기 때문에 이런 툴을 사용하죠. 협업은 서로 메신저를 통해서 개발에 관련된 대화를 하는 걸 말하는데, 사실 카톡이나 사내 메신저를 써도 되는 부분이긴 하지만 그래도 슬렉을 쓰는 가장 큰 이유가 하나 있습니다. 그 이유는 가장 마지막에 설명 드릴께요. 다음으로 [개발]인데인텔리제이나, OpenJDK, 그리고 Spring Boot는 이전에 말씀 드렸고, 밑에 JUnit은 테스트 코드를 작성할 때 필요해요.보통 개발할때 if문 3~4개에 for문도 여러개 섞어서 복잡한 로직을 만들어 내죠. 이게 처음 만들 때는 집중해서 만들기 때문에 로직이 이해 되는데, 하루만 지나도 이 로직이 이해가 안되기 시작해요. 아무래 내가 짠 코드라도 다시 이해하는게 힘들어 지는데, 이럴때는 차라리 입력값을 넣어서 돌려보고, 결과값을 보는 게 로직을 이해하는 데 쉽거든요.그래서 바로 이런 테스트 코드를 만들어 놓는 게 좋고, 혹시라도 다른 사람이 이 로직을 수정하더라도, 테스트 코드를 돌려봐서 기대했던 값이 잘 나오면 안심을 할 수가 있죠. 그래서 코드를 개발할 때 조금만 고생해서 이렇게 테스트 코드도 같이 만들어 놓습니다. 다음으로 코드 분석 이라고 해서 FindBug나 PMD는 내가 짠 코드 패턴에 혹시 모를 버그가 있는지를 체크해줘요. 그래서 잘못된 로직을 짜지 않도록 도와주는데, 이런거 뿐만아니라 개발자간에 미리 코딩 스타일을 정해 놓거나, 개발 편의를 위해서 사용하는 툴 들은 엄청 많습니다. 다음으로 [빌드]를 볼께요.빌드 대상은 소스와 컨테이너고 Gradle과 도커가 사용됩니다. 소스 빌드로 현재 Maven보단 Gradle을 많이 쓰지만 저장소 자체는 메이븐 저장소에서 라이브러리를 가져 오는 거고요. 도커도 이전 [컨테이너 한방정리]에서 많이 얘기를 해서 이번엔 넘어 갈께요. 이제 다음으로 [테스트] 예요.테스트를 해야되는 요소에는 크게 3가지가 있는데, 기능이랑 성능 그리고 커버리지예요.각각 Junit, Jmeter, JACOCO라는 툴 들이 쓰이고. 각자 개발단계에서 테스트 코드를 만들고 실행을 해봤더라도 코드들이 병합되고 나서 또 다른 결과가 나올 수 있기 때문에, 빌드 단계에서 이 JUnit을 실행시켜서 자동으로 테스트를 한번 더 돌려 보는 거예요.그래서 위치는 이렇게 빌드에 연결되서 테스트가 같이 실행되는 거고, 테스트 이후에 Jacoco라는 툴을 돌리면 이 테스트를 돌렸을 때 사용된 로직들이, App 전체에서 어느정도 범위를 테스트 해본 건지, 커버리지를 결과를 알려줍니다.그래서 내가 돌려본 테스트 케이스들이 전체 로직에서 많은 부분을 차지할 수록, 이 App에 대한 신뢰도가 높다고 판단을 해요. 그리고 JMeter는 성능 테스트를 하는 툴 인데, 이건 자동화 기능은 아니고, 여기 개발환경이나 검증환경을 대상으로 진행 합니다. 통상 별도의 성능 테스트 전문 인력이 날잡아서 수동으로 진행하고요. 이제 다음으로 [릴리즈]와 [배포] 입니다.릴리즈는 배포 가능한 패키지를 만드는 과정이에요.도커 빌드를 하기 위해서는 Dockerfile이라는 스크립트를 작성해야 되고, 또 쿠버네티스에 배포를 하기 위해서 yaml 파일들을 사전에 만들어 놔야 되는데 이렇게 배포를 하기 위한 별도의 패키지를 만드는 게 릴리즈고, 이 파일들도 변경관리가 되야 하기 때문에 작성한 내용들을 이렇게 Github에 올려 놓습니다.그리고 배포할 때 사용을 하는데, 이 릴리즈와 이 배포 부분이 이번 Sprint2에서 다루게 될 주요 범위예요. 배포를 하기 위한 툴로는 대표적으로 kustomize와 helm 그리고 argoCD가 있고, 다 Sprint2 강의에서 배우게 됩니다. Sprint1 강의에서는 kubectl로 배포를 했지만, 이제 이런 도구들을 써서 쿠버네티스에 배포를 하게 되는 거죠. 이제 다음 단계로 [운영]입니다. 이건 실제 운영환경을 구성하는 요소와 툴 들이라고 보시면 되요. 여기서 Nginx와 Istio는 네트워크 트래픽 관리에 대한 도구고, 나머지 들은 [쿠버네티스 무겁게 설치하기]에서 나왔던 익숙한 그림일 거예요. 이외에도 운영을 구성하는 환경들은 다 표현하기 힘들 정도 많지만, 이정도로만 하고 이렇게 인프라 환경 안에서 설치되고, 운영자는 이 툴들이 정상적으로 잘 돌아가고 있는지 확인해야 하는 역할을 하죠.그리고 마지막으로 [모니터링]인데,모니터링 요소는 주로 자원 사용량이나 App로그 그리고 트래픽 흐름을 많이 봐요. Grafana 나 Loki 그리고 Prometheus는 Sprint1에서 사용을 해봤고. 이게 자원 사용량이랑 App로그를 보기 위한 툴이였죠?그리고 Jaeger랑 Zipkin은 트래픽 흐름을 보기 위한 도구예요. 이제 마이크로서비스 환경이 많아졌기 때문에 서비스들 간에 트래픽이 어떻게 흘러가는지 추적을 하는게 중요해 졌습니다. 그래서 이런 오픈소스들을 설치해야 되고위치는 운영과 똑같이 인프라 환경 내에 설치가 되요. 이 App들은 다 쿠버네티스 클러스터 위에서 Pod로 띄어 진다고 보시면 됩니다. 그럼 여기까지가 모니터링까지 다 설명을 드린거고, 아까 [Slack을 쓰는 이유]를 마지막에 말씀드린다고 했는데, 딴게 아니라 이렇게 연결되는 그림들이 있어야 되서 그래요. 이렇게 슬렉은 데브옵스에 중요 포인트 차지하고 있는 툴들이랑 연동이 할 수가 있거든요. 통상 메신저에는 개발자나, 데브옵스 엔지니어 혹은 운영자들이 모여 있는 방이 각각 있을 텐데, 슬렉을 쓰면 이 파이프라인에서 발생하는 알람들을 필요한 방에 울리도록 설정할 수가 있는거죠. 그래서 이게 협업을 위한 여러 메신저들 중에서, 그래도 슬렉을 쓰면 좋은 점 이었습니다. 자 그럼 여기까지가 데브옵스를 구성하는 오픈소스들에 대한 설명이였는데, 어떻게 데브옵스가 좀 실질적으로 와닿으시나요? 현재는 이렇게 데브옵스가 복잡해 졌습니다. 그래서 기업에서는 데브옵스 엔지니어를 별도로 뽑을 수 밖에 없는 거고요. 뭔가 많아 보이지만, 그래도 차근차근 하나씩 구성하다 보면 생각보다 금방 파이프라인이 만들어 지기도하고 여기 있는걸 한번에 다 만들 필요는 없어요. 배포를 한다고 처음부터 helm이나 argoCD를 적용할 필요는 없는 거고 Kubectl 배포부터 일단 연결을 해 놓은 다음에 하나씩 장비를 업그레이드 하는 마음으로 바꿔 나가면 되거든요.이번 강의도 그런 스탭으로 구성을 했으니까, 끝까지 잘 따라오시길 바라고요!아래 내용들은 강의에서 자세히 설명 드릴 내용들입니다. 쿠버네티스 어나더클래스 DevOps 전체 구성도 DevOps에서 가장 중요한 것 (개발->빌드->실행파일) DevOps에 엮인 IT 직군들 DevOps 외 다른 Ops들 ps. ♡ make me want to be a better man :)

데브옵스 · 인프라･쿠버네티스･어나더클래스･지상편･Sprint2･일프로･kubernetes･데브옵스･devops･오픈소스

[kubernetes] 손쉽게 데브옵스 환경을 구축하는 방법 #9

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 : https://inf.run/NzKy 이번 강의에서 손쉽게 데브옵스 환경을 구축하는 방법으로 CI/CD 서버를 만들어 볼 건데, 먼저 간략하게 Sprint 2 범위에 실습 환경에 대해서 설명을 드릴께요.[지상편] 실습 환경 (전체범위)[지상편] 최종 실습환경 구성은 여기 보이는 환경들을 모두 설치하는 건데, 각 Sprint 마다 하나씩 환경을 구성해요. 이런 흐름이 내 PC에서 모두 이뤄지는 거고 Sprint1 때는 CI/CD환경이 없기 때문에 인프라 환경만 구성해서, 아래와 같이 실습을 해봤었죠?이제 Sprint2에서 CI/CD 환경을 구성 할 건데, Sprint2 환경 구성 범위먼저 인프라 환경때와 마찬가지로, Virtualbox랑 Vagrant를 이용하면, Guest OS가 만들어 지고, 스크립트를 통해서 이런 프로그램들이 모두 설치 됩니다. 뒤에서 설치 내용은 자세히 설명 드릴 거고요.설치가 다 완료 됐으면, 이제 내 PC에 브라우저에서 Jenkins dashboard를 접속을 할 수가 있게 되요. 그래서 빌드를 실행하면, 저에 Github에서 소스를 다운받아서 빌드가 실행 됩니다. 이 소스는 Sprint1에서 제가 실습을 위해서 만들었던 App에 소스고요.다음으로 컨테이너 빌드를 하면, 소스빌드를 해서 만들어진 Jar 파일이 사용되서 컨테이너 이미지가 만들어지고 Dockerhub로 업로드를 하게 되는데, 직접 도커허브에 가입해서, 내 도커 저장소에 이미지를 올릴 거예요. 그래서 지금까지 이렇게 제 도커 허브 username이 들어간 이미지를 사용했다면, 이제부터 자신이 가입한 username 으로 이미지 이름이 변경됩니다.그리고 도커빌드를 할때 필요한 도커파일이랑 배포를 할때 필요한 yaml 파일들을 저장할 용도로 Github가 필요한데, 기존에 있으신 분들은 그대로 쓰시면 되고요. 없으신 분들은 여기도 가입을 하셔야 되요. 그래서 컨테이너 빌드나 배포를 하면, 제 Github가 아닌, 본인에 Github에서 릴리즈 파일들을 다운 받아서 배포를 하게 되는데여기서 중요한건, 이 배포되는 yaml 파일에 들어가는 image 명에 내 도커허브 username이 있어야 여기서 이미지를 가져 올수 있어요. 이게 이번 Sprint2에 실습 구성과 진행 흐름인데 만약에 좀 헷갈려도 걱정하지 마세요. 한번 더 설명 드릴 꺼에요.단계별 설치 시작먼저 Sprint1에서 했던 것 처럼, 제가 올려놓은 Vagrant 설치 스크립트를 실행하면, 이렇게 CI/CD 서버가 한번에 구성되는데, 이 설치 스크립트에서 일어나는 일을 설명 드릴께요.Vagrantfile로 설치되는 내용먼저, 자원 할당을 보면, CPU 2 core에 Memory 2Gi, Disk 30기가를 줬어요. 그리고 Sprint2 부터는 실습할 때 이 두 환경이 모두 띄어져 있어야 되니까. 내 pc에 자원이 충분한지 확인을 해보시고요.그리고 네트워크 설정을 보시면, IP는 인프라 환경이 30번이었고, CI/CD 서버는 20번 이예요. Host-Only Network는 VM간에 통신을 하거나 내 호스트 PC에서 VM을 접속하기 위한 네트워크라서 IP가 같으면 안되고 근데 이 네트워크는 외부 인터넷에 접속은 안되거든요.그래서 NAT를 추가로 쓰는거고, IP는 자동할당 되는데, 이 IP가 인프라 환경이랑 같지만 인터넷만 쓰기 위한 용도라 문제는 안됩니다.다음으로 여기서 부터가 본격적으로 설치 스크립트에 해당하는 부분인데, 첫번째로 리눅스 기본 설정에 대한 내용들이고 이건 인프라 환경에 쿠버네티스를 설치할 때도 했던 내용이예요.그리고 kubectl을 설치 합니다. 이건 젠킨스에서 배포할때 쓸 용도고여 NAT를 설정해놨기 때문에 이렇게 외부 저장소에서 이 kubectl 패키지를 다운 받아서 설치할 수 있는 거죠. 그리고 마찬가지로 Docker 설치가 있어요. 이걸로 젠킨스에서 컨테이너 빌드를 하고, dockerhub로 이미지를 올리게 되고 다음으로 소스 빌드를 해야되니까 OpenJdk랑 Gradle 설치가 있습니다.그리고 Git도 설치를 해서, 빌드에 쓸 소스 코드랑 릴리즈 파일들을 가져와요.마지막으로 Jenkins를 설치하는데, 이때 OpenJDK를 11 버전으로 하나더 설치해요. 그 이유는 젠킨스가 11버전에 돌아가기 때문에 Jenkins 설치용으로 필요한거고 이건 제가 만든 소스코드가 17버전으로 만들었기 때문에 소스코드 빌드용으로 필요한 거에요. 다시 여길로 돌아와서, 이렇게 Vagrant로 CI/CD 서버가 만들어 졌으면 원격접속 툴로 접속을 해놓고요.그리고 이제 Jenkins 대시보드에도 접속해볼 수 있는데, 여기에 접속하면 최초 젠킨스 초기 세팅을 한번 하게되요. 사용자 생성하고 권장 플러그인들을 다운받는 그런 과정들이 있고 다음으로 전역 설정이라는 걸 하는데, 이게 뭐냐면 이 직접 설치한 버전에 Gradle이랑 OpenJdk를 젠킨스에서 빌드를 할 때 사용하겠다고 등록 하는거예요. 그리고 다음으로 이제 자신에 dockerhub를 써야 되니까 도커허브에 가입하는 단계가 있고요.다음으로 dockerhub 사용 설정이라고 해서, 두 가지가 있는데 첫 번째는 내 CI/CD 서버에서 내 도커허브로 이미지를 올릴 수 있도록 로그인을 해 놓는 거랑 두 번째로 젠킨스에서 docker를 사용할 수 있도록 권한을 부여 해야 합니다.그리고 다음으로 인프라 환경에 있는 인증서를 이 CI/CD 환경에 복사 해줘야 돼요. 그래야 젠킨스에서 kubectl로 배포를 할 때 쿠버네티스에 API를 날릴 수 있습니다.그리고 다음으로 내 Github에 가입을 하고, 설정이 있는데, 설정이 뭐냐면, 제 Github에 Dockerfile이랑 yaml파일들이 있거든요. 이걸 본인이 가입한 Github로 복사해 가는거예요. 그리고 복사하면, Deployment 파일 image 부분에 제 Dockerhub username이 있을 텐데, 이 부분을 수정하는 내용이 있고.마지막으로 젠킨스에서 빌드/배포를 하기위한 프로젝트 설정이 있습니다. 실행버튼을 누르게 되면 쿠버네티스에서 리소스가 생성되고요. 그중에서 Pod를 만들 때 이미지는 이젠 내 도커허브에서 가져가는 거죠.그래서 이렇게가 전체적인 설치 순서고, 이제 두번 정도 설명드릴 셈인데, 어떻게 이해가 잘 되셔나요?뭔가 많아 보일 수는 있는데, 제가 까페에 올려놓는 설치 가이드를 따라하다보면 정말 금방이고 근데 이것도 CI/CD가 흘러가기 위한 최소한에 기능만 쓴거에요. 이 흐름을 시작으로 배포강의가 진행되면서 점점 더 고도화가 됩니다.아래 자세한 설치 가이드가 있는 링크를 걸어 놓을께요.https://cafe.naver.com/kubeops/84만약, 해당 내용으로 설치가 힘드시다면 제 강의에서 설치 실습 영상을 추천 드립니다 :) ps. ♡ make me want to be a better man :)

데브옵스 · 인프라･쿠버네티스･어나더클래스･지상편･Sprint2･일프로･kubernetes･데브옵스･인프런･devops･jenkins