Kubernetes - Review, Volume, ConfigMap

*정리

-쿠버네티스가 없을 때

etho으로 디폴트 네트워크의 ip주소를 받아옴

 

호스트 네트워크(도커의 네트워크 172망), 파드 네트워크(CNI가 만듬+담당), 서비스 네트워크(Kube proxy가 만듬+담당)

 

 

Caliaco

Flannel

Cillium => CeBPF 기반

CNI: 서로 다른 장비에 있는 POD들을 하나의 통신가능한 네트워크로 묶음 

L2 캡슐: Kube Proxy만 해석가능 (↓로 갈수록 캡슐화가 이루어짐)

veth0: ip주소가 없음 -> 단순한 전달/ 입출력 파이프라인 역할만 함 (포트포워딩, 1:1 맵핑)

worker 1,2이 aws 가상머신이라 생각하면 됨, kind는 aws에서 할당받은 서브넷과 동일

 

Ap-northeast-2a: 서울 (2a, 2b, 2c, 2d)

Ap-northeast-2를 서울에 있는 데이터센터라 생각하기

숫자는 지역, a, b, c, d는 각자 층이라 생각 (네트워크가 분리)

 

 

볼륨 생성

볼륨 ID: vol-0918afed928ff2634

할당받은 볼륨 ID로 교체

죽어도 보유(그대로)하겠다! (delete라면 죽으면 바로 삭제, recycle은 볼륨은 그대로 데이터는 포)

 

 

생성한 볼륨(디스크)를 ap-northeast-2a에 놓아라

생성 및 조회

 

-동적할당

Storage Class 조회

 

 

 

*Config Map

ConfigMap과 Secret은 Key Value 쌍으로 데이터를 저장하는 공통점을 가지고 있다.

ComfigMap은 일반적인 Use Cases

  - 환경변수 및 파라미터 전달

  - Container 내부에서 사용되는 명령어 및 매개 변수

  - 어플리케이션이 사용하는 읽기 전용 파일

  - ConfigMap을 읽어서 K8s API를 이용해 Pod 내부에서 수행되는 코드 작성에 이용

  - Secret은 패스워드 및 인증서와 같은 중요정보, 보안용으로 사용 (BASE 64 인코딩, 암호화 X)

 

Immutable ConfigMaps

  - 어플리케이션 오류로 인한 원하지 않는 업데이트로부터 보호

  - 대규모 클러스터에서 성능 개선 : kube-apiserver의 부하를 줄임.  ConfigMap 감시 X

 

 

각 이미지(nginx, mysql, springboot)에는 .conf 파일이라는 설정파일이 有

nginx -> default.conf

springboot -> properties.yaml

mysql -> my.conf

문제점: 개발 / 검증(1차, 2차, 3차) / 운영(1차, 2차) 민감한 서비스일수록 단계 多

-> 개발, 검증, 운영 이런거를 거칠수록 설정파일에 어디에 존재하냐에 따라 변수는 바뀌게 됨!!!

 

ConfigMap: Application과 분리, 참조용 그리고 변수값이 변화 & 마운트

Secret: 암호화 X (암호화보단 인코딩/디코딩에 가깝!)

 

-fortuneloop.sh

 

ex) fortuneloop.sh 30  -> fortuneloop.sh: $1 , 30: $2 (argument라 생각하면 ) // $0: 전 명령어

 

 

 

*CI/CD (Continuous Integration & Continuous Delivery)

 

Continuous Integration: 코드 병합 (Git을 통해서 소스 코드를 충돌 없이 병합(pull-request), 버전관리) ->

이미지(Image)

Commit -> Build -> Test -> Security Checks -> Release

↓

Continuous Delivery(Deployment): 실행 파일을 배포

Deploy Stage -> Deploy Prod

 

Delivery: 갖다 놓고 사람이 실행

Deployment: 갖다 놓고 자동으로 실행

 

새로운 요구사항 -> 우선순위 및 가치 슬라이싱 

↓

initialize change fork ->

Detect new or changed WIP Merge Request to Release Branch ->

CI ->

Continuous Merge Request Deployment ->

Change Development ->

Peer Review->

CI/CD ->

Live Service

 

code-revies

1. 너의 코드가 별로야 - Reject 

2. 왠만하면 변경해라 - Accept

3. 의견 (idea, 이렇게도 해볼 수 있지 않나?) - Accept

 

principle (원칙) - practice (관례 or 관행)

 

현대 CI/CD는 VM이 아닌 컨테이너와 쿠버네티스로 설계!!

 

GitHub Action:

 

워크플로우: 레포지토리안에서 특정 작업을 수행하기 위한 설정가능한 자동화 프로세스

- 테스트 코드 수행

- 패키지 배포

- 슬랙 메세지 전송

- 이슈 오픈 / 전송

- 코드 정적 검사

- 애플리케이션 배포

 

워크플로우 안에 잡 안에 스텝 있는데

jobs는 여러 개 작업 동시에 수행 (병렬)

step은 순차적으로 수행

 

*Runner 비교

항목	Github-hosted Runner	Self-hosted Runner
관리 및 유지보수	Github가 제공하고 유지보수	사용자가 직접 관리
환경 설정	사전 설정된 OS와 툴 제공	원하는 설정과 스펙으로 직접 설정
비용	사용량에 따라 부과 // 퍼블릭 무료	하드웨어 등 유지보수 비용 발생
사용 사례	일반적인 CI/CD 작업	특수하고 고성능 하드웨어 필요한 경우
보안성	매번 실행 할때마다 초기 상태 환경 제공	작업 완료 후 환경 유지