블로그

최신순
인기순
좋아요순

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

기술의 흐름으로 이해하는 컨테이너- 이미지 참고 : 쿠버네티스 어나더 클래스 (https://inf.run/Acobj) 쿠버네티스는 이제 [컨테이너]랑 [가상화] 그리고 [데브옵스]속에 깊숙히 자리잡고 있습니다. 그래서 이 세 가지를 알아야 쿠버네티스를 더 잘 알 수 있게 되는데, 이 단어들은 정말 큰 개념이라서 그냥 용어 설명으로는 이해하기 힘들어요. 그래서 기술에 전반적인 배경을 이해하는 게 중요하다고 생각합니다.그래서 이번 강의는 [컨테이너 한방 정리]로, 쿠버네티스를 잘 이해하기 위해컨테이너를 중심으로한 여러 배경 흐름 들을 이야기 해요. 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가 있습니다. 컨테이너 표준인데, 컨테이너 런타임들은 이걸 잘 지키고 있기 때문에, 우리는 런타임을 바꾸더라도 기존에 만들었던 이미지를 그대로 사용할 수 있어요 블로그는 여기까지고요. 강의가 오픈 되면 링크 걸어 놓을께요.좋은 하루되세요! 해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 :https://inf.run/Acobj 좋아요 ♡는 저에게 큰 힘이 됩니다 :)

데브옵스 · 인프라･인프런･쿠버네티스･어나더클래스･지상편･일프로･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･쿠버네티스편한이유

[쿠어클#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･강의소개

[워밍업 클럽: 쿠버네티스] #3. 실무에서 느껴 본 쿠버네티스가 정말 편 이유 (1주차)

강의 수강 일자 : 25.05.30 (금)블로그 복습 일자 : 25.06.01 (일) 우선 강의를 시작하기 전에, 쿠버네티스를 사용하면서 주로 마주치게 될 카테고리들이 존재하고,카테고리별로 어떤 App을 쓰는지, 어떤 역할을 하는 지 알려준다. [개발] 개발 분야는 웹 서비스에 필요한 개발 도구들을 나열한 것이다.DB, 메세징, 빌드, CI/CD 등 각각 어떤 소프트웨어를 주로 사용하는 지 알 수 있고, 개발부터 배포까지의 흐름을 따라가면 주로 사용할 소프트웨어들이다. [오케스트레이션/매니징]이 부분은 내가 잘 모르는 분야인데, IT서비스를 구축할 때, MSA(마이크로 서비스 구조)로 구축할 때 사용하면 좋은 기술들이라고 한다. 나중에 사용할 일이 있을 때 자세하게 기술해보겠다. [플랫폼 / 런타임]주로 배포 간 클라우드 서비스를 이용할 때 사용하게 될 기술들이다.미션에서 설치했던 컨테이너 런타임, CNI 네트워크, 쿠버네티스들이 보이고, 클라우드 서비스로 유명한 AWS나 NCP도 보인다. 이번 블로그에서 그나마 자세하게 알아볼 카테고리는 [분석] 이다. 쿠버네티스를 사용하기 이전에는 큰 규모의 프로젝트를 생성하려면 개별로 모니터링 및 로깅 시스템을 구축해야 했다.하지만 개발과 분석 시스템을 개별로 구현을 하려면 실제로 다음과 같은 문제들이 발생하게 된다. 개발을 하는 초창기에는 모니터링 시스템을 구축하기가 어려워 로우레벨에서 로그와 성능을 찾아보게 되고,이후 모니터링 시스템이 오픈되어도 이미 익숙해진 로우레벨 방식을 사용하게 된다.이러한 개발 시나리오로 인해 위 사진과 같이 개발과 모니터링 시스템이 엮일 수 밖에 없고, 개발을 편하게 하기 위해 모니터링 시스템을 만들었지만, 개발과 모니터링 방향성이 다르게 흘러가는 상황으로 바뀌게 된다. 심지어 개발이 진행되면서 App의 구현 범위도 상당히 바뀌게 되는데, 이를 모니터링하는 구조도 바꾸다보면 개발 프로젝트와 모니터링 시스템이 서로 다른 범위의 App을 가리키고 있을 수도 있다. -> 그래서 쿠버네티스에서 지원되는 각종 모니터링 / 로깅 툴들을 이용하면,인프라 환경을 구축하면서 개발 초기부터 곧바로 모니터링 시스템을 사용할 수 있고, App 범위가 바뀌어도 자동으로 툴에서 설정을 해주니 편리하게 개발에만 집중하고, 성능이 나오지 않을 때 분석 툴로 도움을 받는 구조가 된다. 아래 링크는 모니터링 툴을 설치해보고, 실제 내 쿠버네티스 파드들을 확인해볼 수 있다.https://cafe.naver.com/f-e/cafes/30725715/articles/30?boardtype=L&menuid=13&referrerAllArticles=false&page=2설치하게 되면 프로메테우스를 가상OS환경에 설치를 하고, 쿠버네티스 파드들을 분석할 수 있다.실제 모니터링을 하는 예시 사진이 아래에 마련되어있다.우리는 모니터링 기술 중 Grafana 툴을 사용해 Pod 성능을 확인할 수도 있고, 로깅 툴 중 Grafana Loki를 사용해 App이 실행될 때 출력되는 로그를 확인할 수도 있다. 쿠버네티스 대표기술들 사용해보기기존에 설치했던 쿠버네티스 파드들을 통해 쿠버네티스 대표 기술들을 알아보려고 한다. 1. Traffic Routing[root@k8s-master ~]# while true; do curl http://192.168.56.30:31221/hostname; sleep 2; echo ''; done;master node 부분에 해당 코드를 입력하면 아래 사진과 같이 두 파드를 번갈아 가면서 트래픽을 보내주게 된다.traffic routing은 App에 파드가 여러 개 일때 트래픽을 분산시켜주는 작업이다. 2. Self-Healing[root@k8s-master ~]# curl 192.168.56.30:31221/memory-leak 코드는 App에 메모리 누수가 나도록 유도하는 코드이고, memory leak이 발생하면 파드 하나가 죽게 되고, 다시 쿠버네티스가 해당 파드를 자동으로 재시작하는 걸 사진으로 볼 수 있다.이처럼 특정 오류로 인해 파드가 죽더라도 쿠버네티스가 감지해 죽은 파드를 재시작해주는 기능이 Self-Healing이다.이로 인해 서비스를 안정적으로 운영할 수 있게 해준다. 3. AutoScaling[root@k8s-master ~]# curl 192.168.56.30:31221/cpu-load위 코드는 App에 부하를 주는 코드이다. 파드마다 CPU 사용량이 40% 이상이 되면 파드를 자동으로 늘려주는 스크립트가 구현되어있고, 이렇게 App의 파드들 만으로 기능이 어렵도록 성능에 무리를 주는 작업이 발생하면, 자동으로 파드들을 늘려주는 기능을 AutoScaling이라 한다. 시간이 지나고 부하가 떨어지면 자동으로 늘렸던 파드 개수를 조정도 해준다. 4. RollingUpdate[root@k8s-master ~]# kubectl set image -n default deployment/app-1-2-2-1 app-1-2-2-1=1pro/app-update 위 코드는 파드를 업데이트 해주는 작업이다. 파드가 Running 중에 있을 때도 업데이트를 하게 될 때, 기존에 있던 파드들이 종료되지 않고, 파드가 새로 생성되고 정상 작동되는 걸 확인하면 기존 파드와 교체를 하는 방식이다.위 기능을 통해 무중단 배포가 가능하게 된다. 정리기존 쿠버네티스를 사용하지 않고, 서비스를 배포할 때 여러 App들을 VM환경에 구축하고,추가로 App을 생성하려면 사람이 직접 왼쪽처럼 세팅을 다 해줘야 했는데,쿠버네티스를 사용하면 이 세팅들이 자동으로 구성이 되도록 코드만 짜주면 추가로 파드를 구성하는게 문제가 없다.이렇게 자동화된 덕분에 서비스를 구축하고 크기를 조정하는 과정이 수월해져 안정성이 더 높아졌다. 또한, 인프라 환경을 코드로 구현해 관리를 하게 되니,인프라 History 관리를 Github를 통해 버전 관리하기 쉬워지고, 기존 작업의 추적도 가능해졌다.또한 인프라 환경은 개발, 검증, 운영 환경으로 나누어 따로 환경을 구축해야 할 때, 그냥 코드 이름만 바꿔서 파일을 생성하면 환경별로 파일이 생성되니 반복 작업을 할 필요가 없어졌다.

데브옵스 · 인프라･k8s･container･Grafana･Loki

[워밍업 클럽: 쿠버네티스] #2. 쿠버네티스 무게감 있게 설치하기 (1주차)

강의 수강 일자 : 25.05.28 (수)블로그 복습 일자 : 25.05.30 (금), 25.05.31(토) 이번 내용에선 쿠버네티스를 내 PC상에 설치를 하는 과정을 복습하면서, 당시에 썻던 스크립트 내용을 하나하나 뜯어보고,왜 이런 스크립트 코드를 썼는지, 실제로 강의의 흐름 없이 쿠버네티스를 내가 직접 설치한다는 가정 하에 복습을 해보겠다. 쿠버네티스를 사용하는 전체 환경 그려보기1) 개발 환경스프링부트와 인텔리제이로 자바 어플리케이션 개발을 하게 되면,Gradle 빌드 툴은 Maven에서 라이브러리를 다운 받아 자바 소스코드를 컴파일해 JAR 파일을 빌드해 JVM 환경에서 실행한다.개발을 완료한 소스코드는 GitHub 저장소에 올리고, 저장소에 올린 소스코드는 CI/CD 환경에서 자동으로 통합과 배포를 진행할 수 있다. 2) CI/CD 환경Jenkins는 내 컴퓨터 환경이 아닌 가상 서버(VM)에서 동작한다.GitHub 소스코드를 다운받고, 해당 환경에 있는 Gradle에 관련 라이브러리를 Maven에서 받는다.Gradle을 통해 소스코드를 빌드해 JAR파일을 만든다.이제 컨테이너 빌드를 하게 될 텐데,먼저 JAR 파일을 실행시킬 OpenJDK 이미지를 도커 허브에서 다운로드 받습니다(도커 허브는 컨테이너 이미지 저장소).이 이미지는 내 JAR 파일을 띄우기 위한 기반이 될 건데, 이를 베이스 이미지라 합니다.베이스 이미지에 JAR 파일을 올리는 걸 완료하면 컨테이너 빌드가 끝납니다.컨테이너 빌드로 생성된 이미지를 다시 도커허브에 올리는 과정까지가 젠킨스에서 빌드를 했을 때 일어나는 과정입니다.이제 배포과정만 남았는데, 배포는 쿠버네티스 측에 Pod 생성 명령을 보내주는 것이 끝입니다.이후에는 인프라 환경 측에서 동작을 합니다. 3) 인프라 환경Pod 생성 명령에는 컨테이너 이미지 주소가 들어있습니다. 쿠버네티스는 주소를 보고 해당 이미지를 다운로드 받게 되고,해당 이미지로 컨테이너를 생성하는 요청을 컨테이너 런타임에 보내줍니다. 개발 환경에는 여러 사람들이 모여 개발한 소스를 GitHub 저장소에 올리고, CI/CD 환경에서 해당 소스코드를 컨테이너 이미지로 인프라 환경에 보내줍니다. 인프라 환경에는 개발, 검증, 운영 환경으로 나눠져 있습니다. 실습에서 진행할 환경 흐름 실습에서는 인프라 환경만 구축을 한다.인프라 구축을 완료하면 브라우저에서 대시보드로 접속을 해 쿠버네티스 오브젝트를 생성할 수 있고,원격 접속 툴로 쿠버네티스가 설치된 OS에 접근을 하면, kubectl을 통해 CLI 통신으로 쿠버네티스에 명령을 보낼 수 있다. 쿠버네티스 설치 및 스크립트 해석하기쿠버네티스 설치개인 PC에 가상환경 VMBox와 Vagrant를 설치하고, 스크립트로 쿠버네티스까지 설치해볼 수 있다.진행한 PC의 OS는 Window10 을 기준으로 진행했습니다. 설치하는 과정은 뇌를 빼고 따라오고, 나중에 미션에서우리가 설치한 것들을 하나하나 살펴볼 예정이니 잘 따라오면 됩니다 ㅎㅎ.. 그럼 시작하겠습니다. Virtual Box 설치 (설치 당시 v7.1.6)https://www.virtualbox.org/wiki/DownloadsVirtualBox 공식 사이트에서 제공하는 다운로드 링크입니다. 들어가면이렇게 PC의 OS 환경에 맞게 VirtualBox를 설치하라고 친절하게 설명 되어있습니다.윈도우 OS에서 설치할 거니 Windows hosts를 눌러 설치해줍니다. Vagrant 설치 (v2.4.3)https://developer.hashicorp.com/vagrant/install?product_intent=vagrantVagrant도 마찬가지로 각 PC의 OS 환경에 맞는 소프트웨어를 제공해주기 때문에, 마찬가지로 윈도우 버전를 선택해 다운 받으면 됩니다. Vagrant 관련 스크립트 다운로드 및 실행윈도우 검색창에 명령 프롬프트를 선택해 아래 스크립트를 그대로 따라 치면 됩니다.# Vagrant 폴더 생성 C:\Users\사용자> mkdir k8s && cd k8scmd에서 현재 위치는 C:\Users\사용자> 이고, 해당 위치에 k8s 폴더를 생성한 후 해당 폴더로 이동하는 명령입니다. # Vagrant 스크립트 다운로드 curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/vagrant-2.4.3/Vagrantfilecurl는 url을 통해 데이터를 다운받을 수 있게 하는 명령이다. 위 명령어를 따라 치면k8s 폴더에 Vagrantfile이 다운받아져 있다.실제로 안에 있는 스크립트 내용이 궁금하다면 들어가서 보고오자.https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/vagrant-2.4.3/Vagrantfile # Rocky Linux Repo 세팅 curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/vagrant-2.4.3/rockylinux-repo.json vagrant box add rockylinux-repo.json 윗 부분과 마찬가지로 이번에는 json 파일을 다운로드 받았다.# Vagrant Disk 설정 Plugin 설치 vagrant plugin install vagrant-vbguest vagrant-disksize # Vagrant 실행 (VM생성) vagrant up위 명령어들을 다 따라하고 나면, k8s에 아래와 같이 파일들이 있으면 정상적으로 실행된거다. vagrant up을 했을 때 뭔가 프롬프트 환경에서 잘 설치가 안된거 같다고 생각이 든다면https://cafe.naver.com/kubeops/26 이 링크에 가서 오류를 해결할 방법을 찾아보자 😂 MobaXterm 설치https://mobaxterm.mobatek.net/download-home-edition.html3단계까지 무사히 잘 마치고, MobaXterm 설치까지 완료 된다면, 우리는 쿠버네티스 환경을 설치한 가상OS에 접속하거나, 할당된 IP로 접근해 쿠버네티스 대시보드까지 확인 가능하다. MobaXterm으로 원격 접속하기- Sessions>New session을 선택해서 접속 세션 생성- 최초 id는 root,password는 vagrant 입니다.세션을 새로 만든 뒤 실행을 하면 프롬프트처럼 검은 화면이 보일 거다.MobaXterm은 쿠버네티스가 설치된 가상 OS에 접근해 쿠버네티스 관련 Pod를 볼 수 있다.혹시라도 Vagrant Up 이후 PC를 종료하면 가상OS가 꺼지니 이후에 가상OS를 키려면다시 cmd 창에 vagrant up을 키면 가상OS를 재기동할 수 있습니다 :D 쿠버네티스 DashBoard 확인하기https://192.168.56.30:30000/#/login링크에 들어가면 쿠버네티스 DashBoard를 확인할 수 있고, 클러스터 노드들을 보게 됩니다. 쿠버네티스를 설치하는 부분까지 잘 따라왔으면, 이제 미션을 따라해볼 수 있습니다!아래 링크에 들어가 미션을 따라하면 쿠버네티스를 설치하는 흐름이 보이고, 강의에서 제공하는 스크립트 코드가 쿠버네티스 공식 문서의 흐름대로 따라가고 있음을 알 수 있습니다!https://inf.run/svj7j

k8s･container･devops

[워밍업 클럽: 쿠버네티스] #1. 컨테이너 한방정리 (1주차)

강의 수강 일자 : 25.05.27 (화)블로그 복습 일자(수정) : 25.05.27 (화), 25.05.28 (수) 인프런 워밍업 클럽을 통해 데브옵스 소프트웨어 중 하나인 쿠버네티스를 배울 수 있는 기회를 우연히 접하게 되었고,어느 새 첫 강의를 듣는 시간이 다가왔다! 나는 데브옵스에 대해 제대로 배워본 적도 없고, 설치나 실습해본 경험도 없다!아예 제로 베이스인 상태로 이 강의를 수강했고, 커리큘럼대로 4주간 꾸준히 진행한다면 이전과는 데브옵스에 대해 자신감있는 모습으로 달라질 미래를 꿈꾸며 그 첫 발걸음을 내딛었다! 가볍게 오늘 배운 이론 지식을 정리해보았다. 컨테이너 (Container)인트로 강의에서 나온 컨테이너의 정의이다. 전체만 봤을 땐 뭔가 어렵고 이해가 잘 안갔지만... 😅문장을 끊어서 차분히 분석하니 다음과 같이 정리해볼 수 있었다.OS 저장공간 일부를 분리해 컨테이너가 사용할 수 있는 공간을 준다.컨테이너는 이 공간에서 기존 OS의 영향을 받지 않는 독립된 프로세스를 실행한다.3. 이러한 독립된 공간은 하드웨어 아키텍쳐가 같은 (CPU, OS 동일) 다른 컴퓨터에서도 동일하게 동작하는 걸 보장한다. 강의 핵심은 컨테이너를 중심으로 여러 배경 흐름을 이야기하고 있다. 크게 기술적인 흐름 (각 영역 별로 어떤 소프트웨어들이 출시 되었고, 점유율의 변화가 어떻게 되는지),컨테이너 런타임의 흐름 (쿠버네티스의 kubelet의 버전 변화를 통해 컨테이너 런타임들이 어떤 변화가 생겼는지) 으로 구분됨.기술 흐름으로 쿠버네티스 배경 이해하기쿠버네티스를 이해하려면 위 그림의 6가지 카테고리를 이해해야 하는데, 차분히 흐름을 따라가보자. Linux OS쿠버네티스를 사용하기 위해선 설치해야 할 OS를 선정해야 하고, 그 중 하나가 리눅스 OS이다.리눅스 OS는 많은 배포판들이 있지만, 우리가 알아야 할 계열로는 1. Debian 계열, 2. Redhat 계열 두 가지다.무료판인 Debian 계열은 Ubuntu를 OS로 사용을 많이 하고, Redhat 계열은 예전엔 CentOS를 사용했지만 시장에서 종료가 되었기 때문에 😂현재로는 1. RHEL 로 전환하여 유료로 사용하는 방법 2. CentOS를 그대로 기술지원을 해주는 기업의 것을 사용하는 방법3. 타 OS로 마이그레이션 스크립트 제공 (다른 OS로 넘어가기)4. RHEL의 복제판인 Rocky, Alma Linux를 사용하기 (무료!)다양한 방법이 있지만, 이번 강의는 Rocky Linux를 OS로 채택하는 방법으로 했습니다. 그래서 Redhat계열로 설치 가이드를 따라가면 됩니다! ContainerLinux OS의 꾸준한 발전으로 격리 기술이 발전되었고, App을 독립적으로 돌릴 수 있게 됐습니다 (컨테이너 핵심개념).chroot(사용자격리, 파일격리, 네트워크 격리), cgroup(자원 격리 (cpu, memory)), namespace (프로세스 격리)위 주요 기술들을 집약하여 만든 Linux Container(LXC) , 최초의 컨테이너이다.LXC를 기반으로 만든것이 우리가 익히 들어본 Docker이다. 이 소프트웨어를 통해 누구나 쉽게 컨테이너를 설치할 수 있게 되었다 (편의성 GOAT). 이 외에도 다른 컨테이너를 보자면,rkt (docker의 보안 취약점을 강화한 컨테이너) , containerd (도커에서 컨테이너 생성만을 분리한 컨테이너), crio-o (redhat에서 만든 컨테이너) 가 있습니다. Container 와 Container Orchestration 비교기존에는 컨테이너만 단독 운영을 했습니다(좌측 그림). App의 버전을 바꿀 때마다 바뀐 App이 컨테이너에서 기동하는지 확인하려면 컨테이너 조회를 사용자가 일일이 확인해야 했고, 기동이 된 걸 확인한 후에 기존 버전으로 흘러갔던 사용자 트래픽을 네트워크 수정으로 바뀐 App으로 전환을 하고, 기존 App를 삭제하는 과정을 거쳐야 하고, 이 과정을 사용자가 직접 조작해야 했습니다.반면 Orchestration을 통해 App의 버전을 바꾸게 되면(우측 그림),사용자가 App의 버전을 바꾸면 쿠버네티스가 알아서 변경된 App의 컨테이너를 생성하고, 해당 컨테이너 기동이 완료되면 네트워크를 수정해 트래픽을 전환해주고, 기존 컨테이너 삭제를 쿠버네티스가 자동화로 처리합니다.App 버전을 바꾸는데 기존에는 컨테이너 생성과 트래픽 수정, 컨테이너 삭제를 사용자가 해야 했지만,App 버전 변경에 대한 명령을 쿠버네티스에 전달하면 앞에서 수행했던 과정들을 쿠버네티스가 알아서 해주는 편의성이 생겼습니다.정리하자면, Container Orchestration의 역할은 다음과 같습니다.1. App을 컨테이너에 담아서 배포한다.2. 시스템 운영 노하우를 많이 가지고 있다. (기존 트래픽 수정, 기존 컨테이너 삭제 등의 자동화)이러한 Container Orchestration에는 다양한 소프트웨어가 있지만(쿠버네티스, 노마드, 도커스왐 등),점유율로는 쿠버네티스가 넘사벽이게 되었고, 우리는 일단 쿠버네티스를 사용하면 됩니다!(굳) 이렇게 오케스트레이션에 쿠버네티스가 1황이 되면서, 이제는 컨테이너들이 쿠버네티스에 호환성이 좋아야 컨테이너를 선택하게 되었습니다. 정리:쿠버네티스는 현재 표준을 넘어 여러 분야에서 활용되고 있다.쿠버네티스는 컨테이너를 더 쉽게 사용할 수 있게 해준다(자동화).컨테이너는 쿠버네티스와의 인터페이스가 중요하다. 컨테이너 런타임으로 컨테이너를 이해하기컨테이너의 커널에는 컨테이너의 핵심 기술이 된 chroot, cgroup, namespace가 커널 레벨의 기술로 되어있고,컨테이너 런타임은 High level, Low level로 나뉘어 사용자 친화성에 따라 구분을 하고 있다.커널 레벨 기술로 만든 LXC는 Low level 컨테이너 런타임으로 되어있고, 도커가 LXC를 기반으로 libcontainer라는 Low level 컨테이너 런타임을 만들었다.libcontainer를 이용해서 사용자 친화적으로 만든 것이 도커이고, 많은 기능들이 들어있다. dockerd에는 컨테이너를 만들어주는 기능 외에 다양한 부가 기능이 많고, 사용자 편의가 좋게 되어있다.컨테이너를 만들어주는 건 containerd이고, containerd는 low level인 libcontainer를 이용하는 것이다.쿠버네티스에서는 도커의 기능 중 컨테이너를 생성해주는 기능만을 주로 사용해서, containerd를 사용한다. 도커가 LXC를 이용하긴 하지만, 둘에 차이점이 존재한다.도커는 App들을 독립적인 환경에 띄우기 위한 목적이고, LXC는 OS를 컨테이너 가상화로 나누기 위한 목적이다.즉, LXC는 기존 VM에서 OS를 가상으로 띄웠던 걸 컨테이너로 OS를 가상화하려는 목적이다. 쿠버네티스가 컨테이너 런타임을 쓰는 방법 쿠버네티스에는 kube-apiserver와 kubelet이라는 컴포넌트가 존재한다.쿠버네티스가 컨테이너를 Pod 단위로 생성하는 API를 호출하게 되면, kube-apiserver는 쿠버네티스로 보내지는 모든 API를 받아, API가 Pod 생성과 관련된 내용이면 kubelet으로 전달한다.kubelet은 Pod 생성에 관한 내용을 보고 컨테이너의 수를 확인해 컨테이너 런타임에 컨테이너 생성 명령을 보낸다.컨테이너 런타임은 요청받은 컨테이너 개수대로 컨테이너를 생성한다. Kubelet으로 보는 쿠버네티스와 컨테이너 런타임 간의 통신방법kubelet은 컨테이너 런타임이 받을 수 있는 API 호출을 하고, 컨테이너 별로 맞춤으로 보낸다(v1.0).컨테이너 런타임이 많아짐에 따라 kubelet의 명령처리도 다양화 되어, kubelet에 알맞는 interface 규격을 정해주고,규격에 맞도록 구현부를 따로 빼어 CRI(Container Runtime Interface)를 만들었다(v1.5).CRI에서 각각의 컨테이너 런타임을 호출하도록 만들었고,컨테이너 런타임 별로 dockershim -> docker , cri-containerd -> containerd, rktshim ->rkt로 구분했다.v1.23이후로는 dockershim이 없어지면서, v1.24에 cri-dockerd로 CRI에서는 지원을 하지 않지만, interface에 docker를 사용할 수 있게 한 미란티스 컨테이너 런타임도 만들어 졌다. 컨테이너는 OCI라는 컨테이너 표준이 정해져 있고, 컨테이너 런타임은 이걸 잘 지키고 있기 때문에, 기존 컨테이너에서 다른 컨테이너 런타임으로 교체를 하더라도, 기존에 만들었던 컨테이너 이미지를 다른 컨테이너 런타임에서도 다시 사용할 수 있게 된다. Kubelet과 CRI는 grpc로 내부 간 통신을 하고, 컨테이너 런타임의 기능이 바뀌면 쿠버네티스도 결국엔 CRI를 바꿔야 했다.그래서 컨테이너 런타임의 기술개발과 쿠버네티스의 기술개발을 별개로 구분하도록kubelet에서 컨테이너 런타임으로 바로 받을 수 있게 구조를 바꿉니다. 각 컨테이너 런타임은 이러한 구조를 지원하기 위해containerd는 CRI-Plugin 기능을 추가하고, cri-o는 해당 구조 규격에 맞게 만든 런타임이고, docker는 cri-dockerd로 되면서 v1.27부터 Pod 생성 시 해당 구조로 컨테이너 런타임과 통신 및 컨테이너 생성을 하게 되었다.

데브옵스 · 인프라･k8s･container