파드 이름에 해시 값 제거

Deployment로 배포 시 파드 뒤에 붙는 해시 값 제거 불가능합니다.

Kind Pod로 배포해야 해시 값을 제거할 수 있습니다.

예시

# test-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: test
spec:
  containers:
  - name: test-pod
    image: test-pod:latest
    imagePullPolicy: IfNotPresent

PV

PV 예시

# pv-definition.yml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mariadb-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem # 파일 시스템 형식
  accessModes:
    - ReadWriteOnce # 3가지 옵션 중 선택 (ReadWriteMany, ReadOnlyMany, ReadWriteOnce)
  storageClassName: manual # StorageClass 이름
  persistentVolumeReclaimPolicy: Delete
  hostPath:
    path: /tmp/k8s-pv # 스토리지를 연결할 Path

Mac에서 Kubernetes 설치

*환경

- Mac m2

설치 방법

*Kubernetes는 Docker Desktop, Minikube, k3s 등으로 설치가 가능한데 Docker Desktop으로 진행

1. OS에 맞게 Docker Desktop 설치

https://www.docker.com/products/docker-desktop/

2. Docker Desktop에서 제공하는 kKubernetes 실행

DDD란?

DDD(Domain-Driven Design), 도메인 주도 설계는 비즈니스 Domain 별로 나누어 설계하는 설계 방법 입니다.

서비스는 고객의 요구사항이나 비즈니스 환경의 변화에 따라 지속적으로 업데이트 되고 변화합니다. 하지만 이러한 변화에 맞춰 시스템의 복잡성을 관리하는 것은 쉽지 않습니다. 이러한 문제를 해결하기 위해 DDD 방법론이 만들어졌습니다.

DDD는 서비스의 ‘기능’을 기준으로 코드를 구분하지 않고, ‘도메인’이라는 비즈니스 영역을 기준으로 코드를 구분하는 것이 핵심입니다.

Event Storming

Event Storming은 서비스와 관계 있는 모든 이해 관계자들이 서로가 가지고 있는 생각을 공유하며, 서비스에서 발생하는 이벤트를 중심(Event-First)으로 분석하는 기법입니다.

Event Storming은 서비스에서 발생하는 주요 이벤트를 중심으로 도메인 모델을 만드는 방법론입니다. 모든 이해관계자들이 참여하여 서비스에서 발생하는 이벤트를 정의하고, 그 이벤트가 어떻게 발생하는지를 함께 이해하려는 접근 방식입니다.

Domain Event

도메인에서 실제로 발생하는 ‘결과’입니다.

실제 요청 사항을 통해 발생한 결과를 ‘도메인 이벤트(Domain Event)’라고 합니다. 이는 서비스에서 발생한 사실, 결과, 특정 행위의 Output을 표현하기 위해 사용됩니다.

Command

도메인에서 특정 주체가 요청하는 ‘행위’입니다.

예를 들어 고객이 “자동차를 대여하겠다”는 요청을 한다면, 이는 Command로 분류됩니다.

Service API 개발 할 때 고려할 사항

1. 설계 및 요구사항 분석
   • API의 목적 정의: 어떤 문제를 해결하기 위한 API인지 명확히 정의.
   • 요구사항 명세: 클라이언트가 필요로 하는 데이터와 기능을 명확히 이해.
   • URI 설계: RESTful API라면 리소스 기반으로 직관적이고 일관된 URI 설계.
2. 성능
   • 데이터 처리량 고려: 예상되는 트래픽과 데이터 양에 맞는 설계.
   • 캐싱 전략: 자주 요청되는 데이터를 캐싱하여 성능 최적화.
   • 효율적인 데이터베이스 쿼리: 데이터베이스 성능을 고려한 쿼리 작성과 인덱스 설계.
   • 비동기 처리: 대용량 데이터 처리를 위한 비동기 프로세스 도입.
3. 확장성
   • 모듈화 설계: 변경 사항이 생겼을 때 최소한의 영향으로 수정 가능.
   • 수평적 확장 지원: 서버를 쉽게 추가하여 부하 분산 가능하도록 설계.
   • 버전 관리: API 버전 관리(V1, V2 등)를 통해 하위 호환성 유지.
4. 보안
   • 인증 및 권한 부여: OAuth2, JWT 등 안전한 인증 방식 사용.
   • 입력 데이터 검증: SQL 인젝션, XSS 등 보안 취약점 방지를 위한 철저한 데이터 검증.
   • HTTPS 사용: 데이터 전송 과정에서 암호화.
   • Rate Limiting: 악성 트래픽이나 과도한 요청 방지를 위한 속도 제한.
5. 개발 및 유지 보수
   • 코드 품질 관리: 일관된 코드 스타일, 주석, 문서화를 통해 유지보수 용이성 확보.
   • 테스트: 단위 테스트, 통합 테스트, 성능 테스트 등을 통한 품질 보증.
   • 로깅 및 모니터링: 장애 발생 시 신속히 대응할 수 있도록 로그와 모니터링 도입.
   • 자동화: CI/CD 파이프라인을 구축해 코드 배포 자동화.
6. 사용자 경험
   • 응답 시간: 최소한의 딜레이로 빠른 응답 제공.
   • 일관된 에러 핸들링: 에러 코드와 메시지를 직관적이고 표준화된 방식으로 전달.
   • 문서화: Swagger 또는 Postman과 같은 도구를 이용해 사용하기 쉬운 API 문서 제공.
7. 기술 스택 및 경험
   • 프레임워크: FastAPI, Express.js, Spring Boot 등 프로젝트에 적합한 프레임워크 선택.
   • 데이터베이스: MariaDB, MongoDB, Redis 등 요구사항에 맞는 데이터베이스 선택.
   • 클라우드 인프라: AWS, Azure, GCP 등 서비스 확장성과 안정성을 위한 클라우드 사용.
8. 배포 환경
   • 컨테이너화: Docker와 Kubernetes를 이용한 이식성과 확장성 강화.
   • 부하 테스트: 실제 트래픽 상황에서의 성능을 사전에 확인.
   • 롤백 전략: 문제가 발생했을 때 빠르게 이전 상태로 복구할 수 있는 전략 마련.

gRPC

gRPC

gRPC는 Google에서 개발되었고 고성능 RPC 프레임워크입니다.

HTTP/2 에서 동작하며 양방향 스트리밍 및 흐름 제어를 제공하며, 원격으로 호출할 수 있는 메서드를 지정하여 서비스를 정의하는 개념이 기반입니다.

protobufs(IDL로 사용)를 기본 메세지 형식으로 사용하여, 효율적인 직렬화가 가능하고 Type 을 명시적으로 체크할 수 있습니다.

gRPC 특징

1. 언어 독립성: gRPC는 다양한 언어를 지원합니다. 클라이언트와 서버가 서로 다른 언어로 작성되어 있어도 상호 작용이 가능합니다.
2. 양방향 스트리밍: HTTP/2를 기반으로 하는 gRPC는 클라이언트와 서버 간에 양방향 스트리밍을 지원합니다.
3. 강력한 타입 체크: 메시지 형식을 프로토콜 버퍼로 정의하면, gRPC는 Type 체크를 제공합니다.
4. 높은 성능: gRPC는 HTTP/2와 프로토콜 버퍼를 활용하여 높은 성능을 제공합니다.
5. Google API 연동: Google API에는 인터페이스의 gRPC 버전이 제공되므로 애플리케이션에 Google 기능을 쉽게 빌드할 수 있습니다.

[Kubernetes]Node Not Ready 분석 및 해결

1. Node 상태 확인
   1. 명령어
      1. kubectl describe node {nodename} 
   2. 상태 확인은 Conditions의 Type에 Message를 보면됩니다.
2. kubectl get pods -n kube-system -o wide를 통해 coredns 파드 상태를 확인*현재 STATUS가 Running으로 문제가 없는 상태인데, Node 는 NotReady 상태
   1. kubectl get pods -n kube-system -o wide
3. NotReady인 노드에서 Kubelet 상태 확인 및 재시작
   1. journalctl -u kubelet
   2. systemctl restart kubelet
4. NotReady인 노드에서 container runtime 상태 확인 및 재시작
   1. systemctl status containerd
   2. systemctl restart containerd
5. Master Node에서 Node 상태 확인
   1. kubectl get node

[Kubernetes]Node, Pod, Container 리소스 사용량 확인

**k8s cpu 는 Milicore (1,000 Milicore = 1 Core)로 표시합니다. Memory 는 Mbyte

[Node 사용량]

• kubectl top node <node-name>

[Pod 사용량]

• kubectl top pod <pod-name> -n <namespace> --containers --use-protocol-buffers

[Pod 내부 Container 별 사용량]

• kubectl top pod —containers=true