pod - 컨테이너, 라벨, 노드스케쥴등으로 설정해서 컨테이너 실행, 파드에 메모리 사용량 미리 적어줄수있음. 안적어주면 문제생김 - 메모리 부족시 다른 파드의 메모리를 사용하여 애플리케이션이 불안정할거나 파드를 스케쥴링할때 마스터노드에서 얼마나 할당해야하는지 메모리 요구사항을 모르기때문에 파드가 다른 노드에 할당되지 않을수있음 마지막으로 자원 낭비

ㄴ라벨 - 키/밸류 형식의 라벨

ㄴ노드스케쥴 - 파드는 노드위에 올라가는데 노드를 직접 지정하거나 아니면 K8S 에서 자동으로 

리밋 - CPU- 낮춤, 메모리-파드 종료

 

 

서비스 - 파드는 재시작하면 아이피가 변경되기때문에 서비스 달아서 파드 연결해줘야함.

ㄴ클러스터아이피 - 외부에서는 접근안되고 클러스터 내부에서만 아이피로 접근 가능함.

ㄴ노드포트 - 클러스터아이피 기능 + 파드가 있는 노드에만 포트가 추가되는게 아니고 파드가 없는 노드까지. 모든 노드에 포트 할당함

ㄴ로드밸런서 -  앞단에서 로드밸런싱으로 파드에 접근되도록(NGINX)

 

 

볼륨 - 

EMPTY DIR - 컨테이너들끼리 데이터를 공유하기 위해 사용, 파드 생성시 같이 생성되고 지우면 같이 지워짐

HOST PATH - 경로 지정해서 사용되며 노드에 저장됨, 파드 재생성시 다른노드에 생성되면 당연히 볼륨 사용불가. 다만 노드별로 마운트해줌 사용은 가능

PV/PVC - pod > pvc > pv > volume 형식으로 연결

 

 

config map - 환경변수 (이미지 1개에 환경변수를 준다) / secret - 보안 환경변수 secret(base64)으로 설정(메모리에 저장됨)

 

namespace - 서비스&파드집합소, 네임스페이스끼리 공유안됨(pv등은 공유됨). 삭제하면 그안의 서비스도 전부 삭제됨

리소스쿼타 - 네임스페이스별로 리소스 쿼타 적용해서 더 올라가지 않도록 한다

리밋 레인지 - 네임스페이스별로 리소스 리밋을 적용해서 넘을경우 파드가 해당 네임스페이스에 들어가지 않도록 한다

 

 

컨트롤러 - 오토힐링, 오토스케일링, 소프트웨어업데이트, 잡등  오케스트레이션 기능들

 

리플리카셋 - 오토힐링,오토스케일링, 자원할당(파드할당) 기능 

 

탬플릿 - 탬플릿에 설정돼있는대로 오토힐링함, 이걸로 버전업그레이드 가능

replicas - 스케일인, 스케일아웃. 

셀렉터 - 파드 지정해서 실행

 

deployment - 파드 배포 방식

recreate - 기존 파드 삭제하고 새로운 파드 생성, 다운타임 발생

롤링 업데이트 - 기존 파드 그대로 두고 새로운 파드 생성후 기존 파드 삭제, 생성/삭제하는 시간동안 기존 파드로 접근되는 문제가 있음. 다운타임 없음.

블루/그린 - 리플리카스를 이용하여 새로운 파드 생성후 서비스를 새로운 파드로 보도록 라벨 변경. 다운타임없고 기존파드로 접근되지도 않음. 롤백도 쉬움. 가장 많이 사용

카나리 배포 - 새버전의 파드를 생성후 일부 트래픽을 새버전의 파드로 가도록하여 테스트.

 

데몬셋 - 모든 노드에 파드가 하나씩 생성. 프로메테우스처럼 모든 노드에 설치되야할 서비스들 설치할때 사용

잡/크론잡 - 임시로 사용할 파드들. 프로세스가 실행되지 않으면 파드 종료.(삭제되는게아님)

 

파드의 라이프사이클 - 파드나 컨테이너의 state 확인

 

서비스 - headless, endpoint, external name

ingress - 로드밸런싱이나 카나리 업그레이드 하기 위해

 

네트워크 - 파드네트워크와 서비스 네트워크, 실 서버의 네트워크를 다르게 줘야함.

 

developer commit
형상&버전관리 - gitlab

build / test / package - jenkins : gitlab에 있는 소스를 불러와서 build하고 test하고 package 한다. 단위test 통과 못하면 fail되어 개발자에게 알람. 단위테스트 통과하면 dev&prod서버에 배포 진행

정적테스트 및 분석 : 소나큐브

IaC, 빌드된 결과물을 운영환경에 배포 : ansible

운영환경 : 쿠버네티스

이런 일련의 과정을 CI/CD 파이프라인

 

젠킨스 설치는 도커 컴포즈로 젠킨스 플러그인 전체 설치

 

jenkins-item이란 : 작업(빌드,배포)최소단위

 

jenkins git plugin 설치

아이템별 git 레포 설정

jenkins maven plugin 설치

메이븐으로 컴파일 - clean compile package

 

jenkins > docker 방법

1) publish over SSH

 

S3란 스토리지 서비스

- 안전하고 가변적인 Object 저장공간을 제공 (ex 구글 클라우드 드라이브, 네이버 클라우드 드라이브)

- 편리한 UI 인터페이스를 통해 어디서나 쉽게 데이터를 저장하고 불러올 수 있음

- 파일 크기는 0KB부터 5TB까지 지원

- 저장공간 무제한

- Bucket 이라는 이름을 사용함(디렉토리와 유사)

- Bucket 은 보편적인 namespace를 사용 : 버킷 이름은 고유해야한다. 리전 상관없이(글로벌설정임)하나의 버킷은 모든 리전에서 고유해야함.

 

S3 object의 구성요소

- Key
- Value

- Version ID

- Metadata

- CORS(Cross Origin Resource Sharing) : 한 버킷의 파일을 다른 버킷에서 접근되도록 해주는 기능(리전 달라도 가능)

 

S3 Data Consistency Model

 - Read after Write Consistency(put) : 파일 업로드시 딜레이없이 바로 사용 가능
- Eventual Consistency(update, delete) : 버킷에 올라간 파일을 update&delete시 결과가 바로 나타나지 않는다. 다만 S3 내부에서는 적용돼있음?

 

S3 스토리지 타입

 - 일반 S3 : 가장 보편적으로 사용되는 스토리지 타입. 높은내구성과 가용성

 - S3 - IA(Infrequent Access) : 자주 접근되지는 않으나 빠른 접근이 요구되는 파일이 많을시 유용, 일반 S3에 비해 비용은 저렴하나 접근시 추가 비용 발생. 멀티 AZ를 통한 데이터 저장으로 가용성이 높음

 - S3 One Zone IA : 단일 AZ에 저장. 상대적으로 낮은 가용성. 데이터 접근시 S3-IA보다 20프로 비용 저렴

 - Glacier : 거의 접근하지 않을 데이터 저장시 유용. 매우 저렴한 비용. 데이터 접근시 대략 4-5시간 소요

 - Intelligent Tiering : 데이터 접근 주기가 불규칙할때 매우 유용, 2가지 티어 존재[Frequent Tier / Infrequent Tier]. 데이터 접근주기에 따라 두가지 티어중 하나로 선택됨. Frequent Tier가 비용이 더 비쌈. 최고의 비용 절감 효율을 누릴 수 있음

 

 

+ Recent posts