Kubernetes

쿠버네티스 환경 이해를 위하여 스터디 그룹을 만들었습니다. 커뮤니티를 사용하여 사람들을 모집하였고, 서로 다양한 정보 공유와 쿠버네티스 환경을 이용한 서비스 개발을 위하여 스터디 그룹을 개설하였습니다. Slack 주소 : https://join.slack.com/t/

온프레미스는 기업의 서버를 클라우드와 같이 '가상의 공간'이 아니라, 자체적으로 보유하고 있는 서버에 직접 설치하고 운영하는 방식으로 고전적인 방식을 의미합니다.오프프레미스란 온프레미스의 반대로 인터넷 네트워크에 연결된 서버팜이나 클라우드의 원격 실행환경을 의미합니다.

컨테이너 인프라 환경은 크게 컨테이너, 컨테이너 관리, 개발 환경 구성 및 배포 자동화, 모니터링으로 구성됩니다.이를 지원하는 도구 가운데 업계에서 가장 많이 사용하는 도구 몇 가지를 알아보겠습니다.컨테이너 환경에서 독립적으로 애플리케이션을 실행할 수 있도록 컨테이너를

이제 본격적인 시작에 앞서 환경 구성을 하겠습니다. 아래는 프로그램 별 버전 정리입니다. 프로그램의 버전이 안 맞을 시 에러가 발생할 수 있습니다. Virtual Box : 6.1.12 https://www.virtualbox.org/wiki/DownloadOldB

vagrantfile을 작성하여 원하는 구성을 자동으로 생성할 수 있게합니다.베이그런트 코드는 루비(Ruby)라는 언어로 작성합니다.아래의 코드를 복사 붙여넣게 하여 C:\\HashiCorp\\Vagrantfile 을 수정합니다.Vagrant.configure("2")

endvagrant upvagrant ssh m-k8s $ ./ping_2_nds.sh // 쉘 스크립트 실행해 가상 머신끼리 통신이 되는지 확인한다.putty와 superputty를 설치해 콘솔 연결을 합니다.

리눅스 운영 체제의 커널 하나에서 여러 개의 컨테이너가 격리된 상태로 실행되는 인프라 환경을 말합니다.가상화 환경에서는 각각의 가상 머신이 모두 독립적인 운영 체제 커널을 가지고 있어야 하기 때문에 그만큼 자원을 더 소모해야하고 성능이 떨어질 수밖에 없습니다.하지만 컨

교재에서 나온 필자의 깃허브 링크에 있는 파일을 다운 받아 실습을 진행하였습니다. 깃허브 링크 : https://github.com/sysnet4admin/Bookk8sInfra Vagrantfile C:\HashiCorp\Bookk8sInfra-main\Bookk

파드 배포를 중심으로 쿠버네티스 구성요소 살펴보기 > [root@m-k8s ~]# kubectl get pods --all-namespaces 관리자나 개발자가 파드를 배포할 때 마스터 노드 0. kubectl 1. API 서버 2. etcd 3. 컨트롤러 매니저

쿠버네티스의 가장 큰 장점은 쿠버네티스 구성 요소마다 하는 일이 명확하게 구분돼 각자의 역할만 충실하게 수행하면 클러스터 시스템이 안정적으로 운영되낟는 점입니다.이렇게 나눠진 것은 마이크로 서비스 아키텍처(MSA) 구조와도 밀접하게 연관됩니다.역할이 명확하게 나뉘여 있

쿠버네티스 클러스터의 정보를 kubectl이 알지 못해 명령을 실행해도 쿠버네티스의 노드들에 대한 정보가 표시되지 않습니다.Kubectl 은 API 서버를 통해 쿠버네티스에 명령을 내립니다.따라서 kubectl 이 어디에 있더라고 API 서버의 접속 정보만 있다면 어느

create 방식 vs run 방식 으로 파드 생성하기create 방식으로 생성한 파드의 이름은 dpy-nginx-c8d778df-st6mz로 이름이 무작위로 생성되지만 run 방식으로 생성한 파드의 이름은 명령어에서 내가 설정한 nginx로 생성됩니다.run으로 파드

쿠버네티스를 사용하는 관점에서 파드와 디플로이먼트는 스펙(spec)과 상태(status) 등의 값을 가지고 있습니다.이러한 값을 가지고 있는 파드와 디플로이 먼트를 개별 속성을 포함해 부르는 단위를 오브젝트라고 합니다 쿠버네티스에서 실행되는 최소단위웹 서비스를 구동하는

기본 오브젝트만으로도 쿠버네티스를 사용할 수 있습니다.하지만 한계가 있어서 이를 좀 더 효율적으로 작동하도록 기능들을 조합하고 추가해 구현한 것입니다.쿠버네티스에서 가장 많이 쓰이는 디플로이먼트 오브젝트는 파드에 기반을 두고 있으며, 레플리카셋 오브젝트를 합쳐 놓은 형

래플리카셋은 파드의 개수를 지정한 3개로 맞춰주는 역할을 합니다.현재 배포된 파드의 상태를 확인 합니다.nginx-pod를 scale 명령으로 3개로 증가 시킵니다. 여기서 --replicas=3은 파드의 수를 3개로 맞추는 옵션입니다.실행하면 리소스를 찾을 수 없다며

디플로이먼트를 생성하면서 한꺼번에 여러 개의 파드를 만들 수 있게 작성하는 파일일반적으로 야믈(YAML) 문법으로 작성합니다.yaml 파일 실행 후 pod 생성 확인sed 명령어로 파일 수정(vi로 수정해도 무관함)변경된 내용을 적용합니다.이미 존재한다는 에러 메세지만

warning 은 오브젝트를 처음부터 apply로 생성하지 않아서 발생하는 오류입니다.경고가 발생하는 건 문제가 되지 않지만 변경 가능성이 있는 오브젝트는 처음부터 apply로 생성하는 것이 좋습니다.

Run VS Create VS Applyhttps://chat.openai.com/share/3c5e240d-94a4-4324-9126-0fa579e1fb67이해한 내용을 기반으로 나만의 정리를 하자면Run : 편리하지만 제한이 많다. run으로 생성한 파드

셀프 힐링 파드의 자동 복구 기술 제대로 작동하지 않는 컨테이너를 다시 시작하거나 교체해 파드가 정상적으로 작동하게 합니다. 파드에 접속하기 위한 파드의 IP를 알아야합니다. 파드 컨테이너의 셸(shell)에 접속합니다. 컨테이너에서 구동하는 nginx의 PID(

파드에 문제가 발생하는 상황을 만들기 위해 앞에서 생성한 파드를 조회 후 삭제하겠습니다.파드의 동작을 보증하려면 어떤 조건이 필요합니다.어떤 조건인지 확인하기 위하여 다른 파드도 삭제해 서로 비교해 봅시다.아래 표시한 파드를 삭제하겠습니다.삭제 후 삭제 확인을 위한 조

노드 쿠버네티스 스케줄러에서 파드를 할당받고 처리하는 역할을 합니다. 최근에 몇 차례 문제가 생긴 노드에 파드를 할당하면 문제가 생길 가능성이 높습니다. 하지만 어쩔 수 없이 해당 노드를 사용해야 한다면 영향도가 적은 파드를 할당해 일정 기간 사용하면서 모니터링해야합니

kubectl drain w3-k8s위의 에러 메세지로 drain이 어떻게 작동하는지 알 수 있습니다.drain은 실제로 파드를 옮기는 것이 아니라 노드에서 파드를 삭제하고 다른 곳에서 다시 생성합니다.파드는 언제라도 삭제할 수 있기 때문에 쿠버네티스에서 대부분 이동은

다음 명령으로 컨테이너 버전 업데이트를 테스트하기 위한 파드를 배포합니다.여기서 --record는 매우 중요한 옵션으로, 배포한 정보의 히스토리를 기록합니다.적용한 코드의 내용은 아래와 같습니다.record 옵션으로 기록된 히스토리는 rollout history 명령을

업데이트 시 실수로 잘못된 버전을 입력했을 때 사용합니다.set image 명령으로 nginx 컨테이너 버전을 의도와 다르게 입력합니다.하지만 이번에는 한참 시간이 지나도 파드가 삭제되지 않고 pending(대기 중) 상태에서 넘어가지 않습니다.어떤 문제인지 확인하기

바로 전 상태가 아니라 특정 시점으로 돌아가고 싶다면 --to-revision 옵션을 사용합니다.새로 생성된 파드들의 IP를 확인합니다.curl -I rollout-nginx 디플로이먼트를 삭제(delete)배포된 파드가 없는지 확인합니다.

쿠버네티스에서는 외부에서 쿠버네티스 클러스터에 접속하는 방법을 서비스라고 합니다.서비스를 '소비를 위한 도움을 제공한다'는 관점으로 바라본다면 쿠버네티스가 외부에서 쿠버네티스 클러스터에 접속하기 위한 '서비스'를 제공한다고 볼 수 있습니다.노드 포트(NodePort)

파워쉘에서 명령어 작성이 명령은 반복적으로 192.168.1.101:30000 에 접속해 접속한 파드 이름을 화면에 표시합니다.파워셸로 코드를 실행하고 쿠버네티스 마스터 노드에서 scale을 실행해 파드를 3개로 증가시킵니다. 그리기ㅗ 배포된 파드를 확인합니다.파워셸

expose 명령어를 사용해 서비스로 내보낼 디플로이먼트를 np-pods로 지정합니다.2.expose를 사용해서 생성하면 노드포트의 포트번호를 지정할 수 없습니다.(자동으로 지정되어 현재 32557로 랜덤 지정 되었습니다.)

인그레스(Ingress)고유한 주소를 제공해 사용 목적에 따라 다른 응답을 제공할 수 있고, 트래픽에 대한 L4/L7 로드 밸런서와 보안 인증서를 처리하는 기능을 제공합니다.Nginx 인그레스 컨트롤러테스트용으로 디플로이 먼트 2개(in-hname-pod, in-ip-

인그레스(Ingress)고유한 주소를 제공해 사용 목적에 따라 다른 응답을 제공할 수 있고, 트래픽에 대한 L4/L7 로드 밸런서와 보안 인증서를 처리하는 기능을 제공합니다.Nginx 인그레스 컨트롤러테스트용으로 디플로이 먼트 2개(in-hname-pod, in-ip-

쿠버네티스에서는 로드 밸랜서라는 서비스 타입을 제공해 다음 그림과 같은 간단한 구조로 파드를 외부에 노출하고 부하를 분산합니다.쿠버네티스에서 로드 배런서를 사용하려면 로드밸랜서를 이미 구현해 둔 서비스업체의 도움을 받아 쿠버네티스 클러스터 외부에 구현해야 하기 때문입니

온프레미스에서 로드밸랜서 사용할 시 내부 로드밸랜서 서비스를 받아주는 구성이 필요한데 이를 지원해줍니다.디플로이먼트를 이용해 2종류의 파드를 생성합니다. 그리고 scale 명령으로 파드를 3개로 늘려 노드당 1개씩 파드가 배포되게 합니다.2종류의 파드가 3개씩 배포 됐

HPA(Horizontal Pod Autoscaler) 여러 사용자가 접근 하는 것을 대비하여 부하량에 따라 디플로이먼트의 파드 수를 유동적으로 관리하는 기능을 제공합니다. 디플로이먼트 생성 앞에서 MetalLB를 구성했으므로 expose를 실행해 hpa-hname-

디플로이먼트의 replicas가 노드 수 만큼 정해져 있는 형태현재 MetalLB의 스피커가 각 노드에 분포돼 있는 상태를 확인합니다.워커 노드를 1개 늘립니다.2.1 Vagrantfile에서 N의 인자 값을 3에서 4로 수정2.2 Vagrantfile이 있는 경로로

컨피그 맵(ConfigMap) 이름 그대로 설정(config)을 목적으로 사용하는 오브젝트 테스트용 디플로이먼트를 cfgmap라는 이름으로 생성합니다 cfgmap을 로드밸런서(MetalLB)를 통해 노출하고 이름은 cfgmap-svc로 지정합니다.

PVC(PersistentVolumeClaim) 지속적으로 사용 가능한 볼륨 요청 손님(사용자)가 원하는 만큼의 피자를 접시에 담아서 가져오는 것 PV(PersistentVolume) 지속적으로 사용 가능한 볼륨 요리사(관리자)가 피자를 굽는 것

PV로 선언할 볼륨을 만들기 위해 NFS 서버를 마스터 노드에 구성합니다.해당 내용을 시스템에 적용해 NFS 서버를 활성화 하고 다음에 시작할 때도 자동으로 적용되도록 systemctl enable --now nfs 명령을 실행합니다.다음 경로에 있는 오브젝트 스펙을

제공받은 파일일로 설정을 하였습니다.실제로 PV 와 PVC를 구성해서 PV와 PVC를 구성한느 주체가 관리자와 사용자로 나뉜다는 것을 확인했습니다. 또한 관리자와 사용자가 나뉘어 있지 않다면 굳이 PV와 PVC를 통하지 않고 바로 파드에 공유가 가능한 NFS 볼륨을 마

파드가 만들어지는 이름과 순서를 예측해야 할 때 사용주로 Redis, Zookeeper, 카산드라(Cassandra), MongoDB, 등의 마스터-슬레이브 구조 시스템에서 필요합니다.VolumeCalimTemplates 기능을 사용해 PVC를 자동으로 생성할 수 있고

파드들은 워커 노드라는 노드 단위로 관리하며, 워커 노드와 마스터 노드가 모여 쿠버네티스 클러스터가 됩니다.파드는 1개 이상의 컨테이너로 이루어져 있습니다.컨테이너들을 돌보는 것이 파드고, 파드를 돌보는 것이 쿠버네티스 워커 이며, 워커 노드를 돌보는 것이 쿠버네티스

docker cp <호스트 경로> <컨테이너 이름>:<컨테이너 내부 경로> 형식으로 호스트에 위치한 파일을 구동중인 컨테이너 내부에 복사합니다.따라서 컨테이너에 임시로 필요한 파일이 있는 경우 단편적으로 전송하기 위해서 사용합니다.컨테이너에 저장돼있는

![](https://velog.velcdn.com/images/yoondonggyu/post/71619a62-ce22-4a79-b160-f6ef1b6c8c89/image.

컨테이너 이미지 생성 방법 1. 기본적인 빌드 2. 용량 줄이기 3. 컨테이너 내부 빌드 4. 멀티 스테이지

2. 컨테이너 용량 줄이기

3\. 컨테이너 내부에서 컨테이너 빌드하기

최적화해 컨테이너 빌드하기

작동 실패 예시 필자의 도커 파일로 실습 후 확인 완료

레지스트리(저장소)

깃허브 등의 저장소에 저장해 둔 애플리케이션 소스를 내려받아 도커 컨테이너 이미지로 빌드합니다. 빌드한 컨테이너 이미지를 쿠버네티스에서 사용할 수 있도록 레지스트리에 등록합니다. 레지스트리에 등록된 이미지를 기반으로 쿠버네티스 오브젝트를 생성합니다. 생성한 오브젝트

바이너리 실행 파일로 짜인 배포 도구입니다. 만약 kubectl이 없다면 직접 코드를 짜서 API 서버에 명령을 내려야합니다.쿠버네티스에서 기본으로 포함된 커맨드라인 도구오브젝트 생성과 쿠버네티스 클러스터에 존재하는 오브젝트, 이벤트 등의 정보를 확인하는 데 사용하는

커스터마이즈는 야믈 파일에 정의된 값을 사용자가 원하는 값으로 변경할 수 있습니다.만약 수정해야 하는 야믈 파일이 많거나 하나의 야믈 파일로 환경이 다른 여러 개의 쿠버네티스 클러스터에 배포하기 위해 Label이나 Name 같은 일부 항목을 수정해야 한다면 매번 일일이

헬름은 쿠버네티스에서 패키지를 손쉽게 배포할 수 있도록 패키지를 관리하는 쿠버네티스 전용 패키지 매니저입니다.일반적으로 패키지는 실행 파일뿐만 아니라 실행 환경에 필요한 의존성 파일과 환경 정보들의 묶음입니다.패키지 매니저는 외부에 있는 저장소에서 패키지 정보를 받아와

https://wookiist.dev/159 블로그를 참고하여 차이점을 비교하였다.

Pending 오류!!

젠킨스 배포 구조 업로드중..

젠킨스 컨트롤러-에이전트 구조 젠킨스 접속 화면

아이템 > > 젠킨스에서 아이템이란 새롭게 정의할 작업을 의미합니다. 작업 순서 정도는 알려줘야 하여 사용합니다. 모든 작업의 정의와 순서를 모아 둔 전체 작업을 프로젝트라고 합니다. 프로젝트를 정의하고 생성하는 것을 아이템이라고 하고, 프로젝트 외에 실제로 작업에

실습 > https://github.com/iac-source/echo-ip 위의 url에 저자가 올려둔 파일을 기반으로 실습을 진행하였습니다. > 젠킨스 Freestyle로 CI/CD를 구성하는 순서 깃허브에서 echo-ip를 빌드할 정보가 담긴 파일들을 내려받습니

개요 > 젠킨스의 Pipeline은 연속적인 작업을 코드 또는 파일로 정의해주는 젠킨스 기능입니다. Pipeline은 고유 문법으로 작성된 코드 또는 이러한 내용을 담고 있는 파일로 이루어져 있습니다. 2가지 문법 코드 스크립트 문법 젠킨스 에이전트를 설정할 때 스

쿠버네티스는 컨테이너들을 관리해주는 일을한다.(오케스트레이션)조금 더 효율적으로 애플리케이션을 활용할 수 있다.사용자가 관리할 것은 별로 없다.설치를 하기 위해 커널에서 설치를 해야한다.

쿠버 시스템 밑에 쿠버네티스의 구성 요소들이 있다.MSA 아키텍처

파드만 배포된 경우죽으면 다시 생성해야한다.디플로이먼트 형태로 배포된 파드(숫자 유지)대처 가능디플로이먼트로 생성한 파드는 삭제하면 알아서 다시 생성된다. 따라서 디플로이먼트로 생성한 파드를 삭제하려면 디플로이먼트 자체를 삭제해야한다.

kubectl edit deployment del-deployreplicas : 3 --> 파드의 개수를 수정파드는 지워지더라도 볼륨에 기록이 남는다.볼륨은 영속성의 띄는 것이다.https://velog.io/@ragnarok_code/%EB%94%94%EC%

https://kubernetes.io/ko/docs/home/