DevOps TIL

Artifact Hub URL: https://artifacthub.io/ 쿠버네티스 패키지 저장소 원하는 패키지를 검색해서 접속하면 해당 레포지토리 추가 및 배포를 하는 방법을 볼 수 있음 레포지토리 추가 등록 helm repo add bitnami https://charts.bitnami.com/bitnami 조회 helm repo list Chart 검색 helm search repo bitnami | grep tomcat 업데이트 helm repo update 삭제 helm repo remove bitnami 배포하기 배포 명령어 helm install my-webserver bitnami/tomcat --version [버전] --set persistence.enabled=false --set ..

Helm 설치하기 curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh Helm 버전 확인하기 helm version 쿠버네티스 config 파일 확인 cd ~/.kube/ ls helm 자동완성 source

Helm이란? 쿠버네티스의 패키지 매니저 Helm v1(2015) Helm v2(2016~2018) 구글 프로젝트에 합류한다음, CNCF에 합류함 Helm v3(2019~현재) Helm을 사용하는 이유 yaml 은 정적 파일이기 때문에 리소스별로 yaml파일을 만들어야 함 많은 리소스를 관리하게 될 때 yaml파일에 대한 유지보수가 힘듦 하나의 Template을 통해 yaml파일을 동적으로 생성하게 해주는 Tool이 필요 배포관리가 편해짐 기타 - 많은 팀들이 클러스터 하나에서 다른 클러스터로 파일을 복사하는 실수를 함 - 이것이 위험한 이유는 이제 모든 파일을 서로 동기화된 상태로 유지할 책임이 있기 때문임 - 개발과 운영사이의 차이가 생길 수 있음 대안 [헬름] 쿠버네티스의 다양한 템플릿 시스템 중 ..

참고: Kubernetes Best Practices(Brendan Burns 외) 1. 애플리케이션 외부 노출 - 외부 IP 주소를 할당해주는 서비스(service)와 로드 밸런서(Load balancer)를 생성하고 컨테이너로 트래픽을 보내야 함 a. 서비스 -> TCP(전송 제어 프로토콜) 또는 UDP(사용자 데이터그램 프로토콜) 트래픽을 로드 밸런싱 b.인그레스 리소스 2.인그레스 - HTTP경로와 호스트 기반의 요청을 지능적으로 라우팅할 수 있는 HTTP(S) 로드 밸런싱 지원 - 앞단에 인그레스를 배치하면 향후 서비스 확장 측면에서 유연성을 확보할 수 있음

스테이트풀(stateful) 애플리케이션 - 동적으로 프로비저닝 될 수 있으므로, 필요 시 기본 볼륨이 생성됨 - 영구 디스크 스토리지에 데이터 저장 ex) 데이터베이스, 키-값 저장소 K8s 에서는 StatefulSet 컨트롤러를 사용하여 객체로 배포 스테이트리스(stateless) 어플리케이션 - 클러스터 또는 영구 스토리지에 데이터 또는 애플리케이션 상태를 저장하지 않는 애플리케이션 - 대신 데이터 및 애플리케이션 상태가 클라이언트에 유지됨 ex) 프론트엔드 K8s 에서는 Deployment 컨트롤러를 사용하여 스테이트리스 애플리케이션을 단일의 비교유 pod으로 배포함

깃옵스(GitOps) : 애플리케이션의 배포와 운영에 관련되 모든 요소를 코드화 하여 Git에서 관리(Ops)하는 것 - 위브웍스(Weaveworks Inc.)에서 처음 사용한 용어로 프로젝트에 데브옵스를 적용하는 실천 방법 중 하나 ***위브웍스는 쿠버네티스가 깃옵스의 대상이라고 말함 - Cloud-native 애플리케이션을 대상으로한 지속적 배포(CD)에 초점을 두고 있음 1.선언형 모델(Declarative Model) 깃옵스의 기본 개념은 코드를 인프라를 프로비저닝하는 IaC에서 나온 것이다. 명령형 모델과 선언형 모델이 있지만 선언형 모델은 데릭토리가 이미 존재하는지 확인하거나 OS에 따라 바뀌는 명령어를 사용자가 알아야 할 필요가 없다 2.단일 진실 공급원(Single Source Of Tru..

쿠버네티스 클러스터: 노드(컨네이터화된 앱)라고 불리는 워커머신으로 구성됨 노드: 어플리케이션 워크로드의 구성요소인 파드를 호스팅 컨트롤 플레인: 워커 노드와 클러스터의 파드들을 관리함 컨트롤 플레인 컴포넌트 칸트롤 플레인은 클러스터 내의 어떤 머신에서도 실행됨 1.kube-apiserver 2.etcd 3.kube-scheduler 4.kube-controller-manager 5.cloud-controller-manager 노드 컴포넌트 kubelet kube-proxy container runtime Addons DNS Web UI(대쉬보드) container resource monitoring cluster-level logging

apiVersion: v1 kind: Pod metadata: name: hostpath-pod spec: containers: - name: hostpath-pod image: nginx volumeMounts: - mountPath: /hostpath name: hostpath-volume volumes: - name: hostpath-volume hostPath: path: /tmp/hostpath # 해당 디렉토리가 존재해야 합니다. type: Directory hostPath: 노드의 디스크에 볼륨을 생성하고, pod이 삭제 되더라도 볼륨에 있던 데이터는 유지 됨 volumeMounts.mountPath: 실행된 컨테이너 안에 마운트할 경로. (자동생성) volumeMounts.name: 마운트..

Dockerfile FROM nginx MAINTAINER 작성자 RUN mkdir /homepage WORKDIR /homepage RUN mkdir ./build COPY ./Homepage/build ./build RUN rm /etc/nginx/conf.d/default.conf ADD ./nginx.conf /etc/nginx/conf.d EXPOSE 80 CMD ["nginx", "-g", "daemon off;"] Yaml #Deployment apiVersion: apps/v1 kind: Deployment metadata: name: homepage-deployment labels: app: web spec: replicas: 1 selector: matchLabels: app: web ..

apiVersion: v1 kind: Pod metadata: name: ubuntu spec: containers: - name: ubuntu image: ubuntu:latest command: [ "/bin/bash", "-c", "--" ] # Just spin & wait forever args: [ "while true; do sleep 30; done;" ] 컨테이너에서 task가 절대 끝나지 않을 명령어를 추가 command: [ "/bin/bash", "-c", "--" ] args: [ "while true; do sleep 30; done;" ]