Fullstack-Study-241204-250625

커리큘럼(12-30/변경)

01. Java
02. git
03. Database 
04. Jsp [Server]

05. HTML,CSS 
07. JS
06. 미니프로젝트-2W

08. SpringFramework , SrpingBoot 
19. 중간프로젝트 (1M)
10. Linux 명령어
11. AWS
12. Docker
13. Kubernetes(v)
14. React JS [Front-end]
15. App - Android
16. 최종프로젝트 (1M)

쿠버네티스

레플리카세트(ReplicaSet)

특정 수의 동일한 Pod 복제본이 항상 실행되도록 보장하는 쿠버네티스의 컨트롤러 리소스
pod를 강제 삭제시, service는 살아있지만 pod가 다운되었기 때문에 애플리케이션이 실행되지 않음 -> pod의 생명주기가 끝남
파드의 집합을 감싸는 또 하나의 오브젝트
파드 집합의 실행을 항상 안정적으로 유지하는 것으로 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용
replicas 1은 파드가 죽더라도, 하나더 생성할 수 있다는 것을 의미
즉 replicas가 3개라면 이중 몇개가 삭제되었더라도 3개의 pod가 실행되도록 복제됨

# first.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: webapp # ReplicaSet 객체의 "이름"입니다 (Service와 무관)

spec:
  selector: 
    matchLabels: 
      app: webapp # 아래에 있는 template.labels.app과 연결되서 파드 관리
  replicas: 1
  template: # 복제할 포드를 템플릿으로 정의함
    metadata:
      labels:
        app: webapp # 서비스와 연결

    spec:
      containers: 
      - name: webapp 
        image: coding404/k8s-coding404-webapp-react:v0-1
kind: ReplicaSet : 리소스의 유형이 레플리카셋임

selector.matchLabels : 레플리카셋이 관리할 Pod를 고르는 기준

replicas : 유지하려는 Pod 복제본 수

template : 레플리카셋이 복제할 Pod의 템플릿

spec.containers : 생성할 Pod 안에 실행할 컨테이너 목록

디플로이먼트(Deployment)

레플리카셋과 파드의 정보를 동시에 관리
레플리카셋보다 상위 오브젝트 개념
애플리케이션의 업데이트와 배포가 편함
릴리스를 통한 롤링배포(업데이트)로 롤아웃을 가능하게 함

롤아웃 : 새 버전을 점진적으로 배포하는 전체 과정

롤링배포 : 기존 인스턴스를 조금씩 교체하며 배포

롤링배포

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp

spec:
  minReadySeconds: 30 # Pod가 Ready 상태가 된 후에도 최소 30초간 더 기다려야 다음 단계로 넘어감.
  selector: 
    matchLabels: 
      app: webapp # 아래에 있는 template.labels.app과 연결되서 파드 관리
  replicas: 2
  template: # 복제할 포드를 템플릿으로 정의함
    metadata:
      labels:
        app: webapp # 내가 service와 연결됨~~

    spec:
      containers: 
      - name: webapp 
        # image: coding404/k8s-coding404-webapp-react:v0 # 기존버전
				image: coding404/k8s-coding404-webapp-react:v0-1 # 버전을 올려봅니다

히스토리 관리

kubectl rollout status deploy 디플로이명

롤아웃 리스타트 - 현재 deploy 재시작

kubectl rollout restart deploy 디플로이명

디플로이 변경 버전 이력 확인

kubectl rollout history deploy 디플로이명

해당 이력으로 롤백하기

kubectl rollout undo deploy 디플로이명 # 바로직전으로 롤백 kubectl rollout undo deploy 디플로이명 --to-revision=1

쿠버네티스 네트워크

하나의 pod안에는 여러 컨테이너가 들어갈 수 있으나 좋은 방법이 아님

포드의 관리가 더 복잡해질 수 있음

포드에서 문제 발생시, 어느 컨테이너에서 발생한 문제인지 찾기 어려움

서비스가 포드에 종속됨

NodePort & ClusterIP

항목 ClusterIP NodePort

기본목적 클러스터 내부통신전용 외부에서 클러스터안으로 접속허용

접근가능위치 클러스터내부에서만접근가능 외부(노드IP+포트)에서 접근가능

할당되는 IP 클러스터내 가상IP(ClusterIP) 각Node에 열린 고정포트(30000~32767)

트래픽흐름 내부Pod → Service → 연결된Pod 외부요청(NodeIP:Port) → Node → Service → Pod

사용예시 마이크로서비스 내부호출용 간단한 테스트용 외부오픈, 작은서비스용

항목	ClusterIP	NodePort
기본목적	클러스터 내부통신전용	외부에서 클러스터안으로 접속허용
접근가능위치	클러스터내부에서만접근가능	외부(노드IP+포트)에서 접근가능
할당되는 IP	클러스터내 가상IP(ClusterIP)	각Node에 열린 고정포트(30000~32767)
트래픽흐름	내부Pod → Service → 연결된Pod	외부요청(NodeIP:Port) → Node → Service → Pod
사용예시	마이크로서비스 내부호출용	간단한 테스트용 외부오픈, 작은서비스용

1. NodePort

외부에서 클러스터 안으로 접속 허용

2. ClusterIP

각 서비스는 쿠버네티스 클러스터 아이피를 통해 통신
서비스를 시작할 때 IP는 임의로 할당됨
서비스 실행시 IP주소가 바뀌는 것은 DNS시스템으로 해결 가능

큐브DNS(kube-dns)와 네임스페이스

큐브DNS

별도의 작업을 하지 않아도 백그라운드에서 자동으로 실행되는 서비스
실행되는 서비스의 IP주소를 전적으로 관리
숨겨져 있기 때문에 특정 명령문을 통해 확인 가능

네임스페이스

네임스페이스는 각 포드들을 식별하기 위한 이름
네임스페이스를 넣지 않으면 default에 네임스페이스를 지정하고, 리소스들만 표시 되게됨
쿠버네티스 리소스를 논리적으로 구분하기 위한 폴더 또는 프로젝트 영역 같은 역할
네임스페이스 목록보기

kubectl get ns

kube-system에 할당된 pod확인

kubectl get all -n kube-system

큐브 DNS로 내부에서 DB접근

pod에 데이터베이스 설치 후 service연결

# postgres.yaml

apiVersion: v1
kind: Pod
metadata:
  name: postgres
  labels:
    app: postgres
spec:
  containers:
  - name: postgres
    image: postgres:14 # 포스트그레 공식 도커 이미지
    env:
    - name: POSTGRES_USER  # 초기슈퍼사용자 유저명
      value: "postgres"
    - name: POSTGRES_PASSWORD  # 비밀번호
      value: "1234"
    - name: POSTGRES_DB  # 기본 데이터베이스 이름
      value: "postgres"
    - name: PGDATA  # 데이터 저장 경로 (선택적)
      value: "/var/lib/postgresql/data/pgdata"
--- 
kind: Service
apiVersion: v1
metadata:
  name: database-postgres
spec:
  selector:
    app: postgres # 메타데이터의 label값
  ports:
    - name: dbport
      port: 5432
  type: ClusterIP # 외부에서는 볼 수 없고, 내부에서 다른 pod가 참조할 수 있도록 함

webapp pod안으로 들어가서 database서비스 발견

웹앱 파드로 접속 kubectl exec -it pod pod명 -- sh

DNS이름이 확인 가능한 파일 열어보기

cat /etc/resolv.conf

kube-dns에 database의 아이피주소 요청

nslookup database-postgres

webapp내부(리눅스) 에서 database연결

apk update
apk add postgresql-client

postgres 접속 데이블생성

# -h 접속아이피
# -U 유저명
# -d 데이터베이스명
psql -h database-postgres -U postgres -d postgres
# 비밀번호 1234

# 테이블 생성
create table example (test varchar(255));

# 테이블 확인하기
\dt

정규화된 DNS 규칙

default 네임스페이스라면, 컨테이너를 구분하는 주소는

<컨테이너명>.default.svc.cluster.local

default 네임스페이스가 아니라면, 컨테이너를 구분하는 주소는

<컨테이너명>.<네임스페이스>.svc.cluster.local

서비스를 찾을 떄 동일한 namespace에 할당되어 있다면, 오브젝트명으로 연결이 가능

하지만, 다른 namespace에 등록된 서비스를 찾는다면 오브젝트명.네임스페이스명.svc.cluster.local형태로 연결해야함