행복을 찾아서

kubectl 이 아닌 Helm 을 써야한다배포를 위한 부가적인 기능을 위해, 자원생성을 잘 하기위해 Helm 과 kustomize 를 패키지 매니저라고 부른다Helm vs kustomize공통점중복관리 최소화다양한 배포툴에서 지원차이점Helm배포할 대상이 늘어날수록 좋음함수방식생태계 더 강력하다kustomize소규모프로젝트일수록 좋음오버레이방식1.14버전부터 kubectl 에 포함헬름배포하기초기화api-tester : 메인차트폴더 (main app 배포)charts : 서브차트폴더 (마이크로서비스의 sub app 배포)templates : 메인차트 yaml 파일 폴더tests : 메인앱 배포후 통신되는지 확인 (부가확인)helpers.tpl : 사용자 정의 전역변수NOTES.txt : README, 배..

Step1. 젠킨스 파이프라인 기본구성Step2. Github 연결 및 파이프라인 세분화Step3. Blue/Green 배포Green 배포에서 쿠버데쉬보드에서 정상적으로 배포완료된걸 보고 전환해야할듯Step4. 버튼한번으로 자동배포while (returnValue != "true true"){ returnValue = sh(returnStdout: true, encoding: 'UTF-8', script: "kubectl get -n anotherclass-221 pods -l instance='api-tester-2214',blue-green-no='2' -o jsonpath='{.items[*].status.containerStatuses[*].ready}'") echo "${returnV..

소스빌드 : 그래들컨테이너빌드 : 도커배포 : kubectl (or HELM, Kustomize )→ Jenkins Pipeline 으로 합치기 가능 그러나 관리담당자를 어떻게 나누냐에 따라 다름→ ArgoCD : 하나만 운영할지 여러개 운영할지 상황에따라 유연하게→ 도커대체 : 데몬필요 + 무겁다 → buildah, podman, skopeo (자원사용률이 낮음)배포recreate → 다운타임존재rollingupdate → 많은 자원사용, 서비스중단없음blue/green → 기존운영환경에서 오래동안 사용, 롤백이빠름, 자동배포가능유즈케이스 : 운영에서만 테스트 가능한 경우canary → ingress 로 트래픽량 조절, 콜드스타트방지A/B 테스트 : V1, V2 비교데이터베이스 변경시 수동으로 할수밖에..

echo '======== [1] Rocky Linux 기본 설정 ========'echo '======== [1-1] 패키지 업데이트 ========'# 강의와 동일한 실습 환경을 유지하기 위해 Linux Update 주석 처리# yum -y updateecho '======== [1-2] 타임존 설정 ========'timedatectl set-timezone Asia/Seoulecho '======== [1-3] 방화벽 해제 ========'systemctl stop firewalld && systemctl disable firewalldecho '======== [2] Kubectl 설치 ========'echo '======== [2-1] repo 설정 ========'cat 저장소 경로yum..

계획Jira, Notion, REDMINE, Slack [데브옵스의 파이프라인 알람을 연결가능]개발JAVA, OpenJdk, SpringBoot, JunitCI빌드Gradle, Maven, Nexus, docker테스트Junit, Jmeter, JACOCOCD릴리즈DockerfileYaml배포argoKustomizeHelmDockerhub운영nginx, callico, istio, containerd, etcd모니터링prometheus, Grafana, loki, zipkin, jagerGitOps : 파이프라인을 Git 하나로DevSecops : 빠른배포와 보안, sonarqube, Trivy(이미지 보안)Mlops : 머신러닝, AI를 위한 데브옵스kubeflow (데이터분석가)AirflowKnati..

Pod가 생성되는 과정 + Probkubectl → kube-apiserver → etcd → Deployment 생성kube-controller-manager → Deployment 발견 → ReplicatSet 생성kube-controller-manager → ReplicatSet 발견 → Pod 생성kube-scheduler → pod를 띄울 노드 스케쥴링 → kube-apiserver → kubelet → containerDkubelet → probe체크 → 컨테이너서비스 동작kubelet → kube-proxy → 네트워크연결요청 → iptables 업데이트 → calico가 컨테이너로 연결Secret노드의 메모리영역에 마운트됨 (물리적 보안)많은 데이터를 사용하면 메모리부족가능성HPAHPA m..

스토리지를 로컬로 사용하기때문에 스토리지관련은 다음기회에PV/PVCresource, accessModes : 둘다 같은 내용이여야함PV 의 local 을 쓰면 필수로 nodeAffinity 가 들어감, 어느 Node에 파드를 생성할것인지hostPath를 써서 nodeSelector 로 지정해도된다, 단 가능하면 사용하지 않는게 좋다 왜냐하면 노드의 정보를 App에서 조회할 일이 있을경우가 사용처라서 운영에서는 비추천노드의 저장공간은 한정되있음파드, PVC를 만드는 주체는 개발자, PV는 인프라의 영역으로 구분Deploymentstrategyrecreate : 모두삭제후 새로운 파드만듬, 서비스중단이 발생RollingUpdate : 새버전파드를 먼저만들고 기동완료되면 기존파드 하나씩 삭제함maxUnavai..

App에 외부변수 및 암호화된 데이를 주입apiVersion: v1kind: ConfigMapmetadata: namespace: anotherclass-123 name: api-tester-1231-properties labels: part-of: k8s-anotherclass component: backend-server name: api-tester instance: api-tester-1231 version: 1.0.0 managed-by: dashboarddata: spring_profiles_active: "dev" application_role: "ALL" postgresql_filepath: "/usr/src/myapp/datasource/post..

startupProbe: httpGet: path: "/startup" port: 8080 periodSeconds: 5 failureThreshold: 36readinessProbe: httpGet: path: "/readiness" port: 8080 periodSeconds: 10 failureThreshold: 3livenessProbe: httpGet: path: "/liveness" port: 8080 periodSeconds: 10 failureThreshold: 3기동중startupProbe : 10초에 한번씩 날림, 성공하면 중지초기화되는동안은 실패기동완료readinessProbe : 성공했을때 외부트래픽 받을수있도록함내부API 성공 후에 ..

마스터 노드에 디렉토리 생성mkdir -p /root/k8s-local-volume/1231label(라벨)앱정보를 바로 파악할수있음셀렉터와 매칭하여 두 오브젝트를 연결prefix 는 도메인이며 권고사항part-of : 어플리케이션의 전체이름component : 서비스를 구성하고 있는 각각의 분리된 기능name : 어플리케이션 실제이instance : 여러 어플리케이션설치할때 값을 다르게 해서 설정 (name-식별자) = 오브젝트 네임version : 앱버전 변경되면 버전수정managed-by : 생성주체확인용도selector(셀렉터)오브젝트들 끼리 연결하기위해 사용 (꼭 이거만있는건 아님)셀럭터의 내용이 모두 레이블에 포함되어있어야함레이블에 추가로 더 있는건 괜찮음인스턴스만 넣어도됨Namespace오브..