System Delay
in blog on Network, Delay
System delay 관련 내용
Delay
Pod 라이프사이클 관리
- 애플리케이션의 배포, 운영, 확장, 그리고 종료까지의 모든 단계를 포함
- Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼을 사용하여 Pod의 라이프사이클을 관리하는 것이 일반적
| 주요단계 | 내용 |
|---|---|
| Pending | Pod가 클러스터에서 승인되었지만, 아직 실행 준비가 되지 않은 상태 (이 단계에서는 네트워크를 통해 컨테이너 이미지를 다운로드하는 시간도 포함) |
| Running | Pod가 노드에 바인딩되고, 모든 컨테이너가 생성된 상태 (적어도 하나의 컨테이너가 실행 중이거나 시작 또는 재시작 중) |
| Succeeded | Pod 내의 모든 컨테이너가 성공적으로 종료된 상태 |
| Failed | Pod 내의 하나 이상의 컨테이너가 실패로 종료된 상태 |
| Unknown | Pod의 상태를 알 수 없는 경우 (일반적으로 노드와의 통신 오류로 인해 발생합니다.) |
k8s 에코시스템
- 컨테이너화된 애플리케이션의 배포, 관리, 확장을 자동화하는 다양한 도구와 서비스의 집합을 의미
에코시스템은 Kubernetes를 중심으로 다양한 오픈 소스 및 상용 솔루션이 함께 작동하여 클라우드 네이티브 애플리케이션을 효과적으로 운영할 수 있도록 지원
- Kubernetes 에코시스템의 주요 구성 요소
| 주요구성요소 | 설명 |
|---|---|
| 컨테이너 런타임 | Docker, containerd, CRI-O 등 다양한 컨테이너 런타임이 Kubernetes와 함께 사용됨 |
| 네트워킹 | Calico, Flannel, Weave 등 네트워킹 솔루션이 클러스터 내에서의 통신을 관리 |
| 스토리지 | Ceph, GlusterFS, Longhorn 등 다양한 스토리지 솔루션이 데이터 저장을 지원 |
| 모니터링 및 로깅 | Prometheus, Grafana, ELK 스택 등이 클러스터의 상태를 모니터링하고 로그를 수집 |
| CI/CD | Jenkins, GitLab CI, Argo CD 등 지속적 통합 및 배포 도구가 애플리케이션의 자동 배포를 지원 |
| 보안 | Istio, Linkerd, OPA 등 서비스 메쉬와 정책 관리 도구가 보안을 강화 |
접근제어
- 접근제어 유형
| 접근제어 | 설명 |
|---|---|
| RBAC(역할 기반 접근 제어) | 사용자가 시스템, 네트워크 또는 리소스에 접근할 수 있는 권한을 역할에 따라 관리하는 방법</br>각 사용자는 하나 이상의 역할을 할당받고, 각 역할에는 특정 권한이 부여 |
| ABAC(속성 기반 접근 제어) | 속성을 기반으로 접근 권한을 부여함</br>예를 들어, 사용자 속성(부서, 직급), 리소스 속성(파일 유형, 보안 등급), 환경 속성(접속 시간, 위치) 등을 조합하여 접근 권한을 결정</br>ABAC는 유연성과 세밀한 제어를 제공하지만, 설정과 관리가 복잡할 수 있음 |
| PBAC(정책 기반 접근 제어) | 정책에 따라 접근 권한을 부여함</br>정책은 특정 조건을 만족할 때 접근을 허용하거나 거부하는 규칙의 집합</br>>예를 들어, 특정 시간대에만 접근을 허용하거나, 특정 네트워크에서만 접근을 허용하는 등의 정책을 설정할 수 있음 |
| MAC(강제 접근 제어) | 중앙 관리자가 설정한 규칙에 따라 접근 권한을 부여함</br>사용자는 자신의 권한을 변경할 수 없으며, 모든 접근 제어는 중앙에서 관리</br>주로 군사나 정부 기관에서 사용되며, 보안이 매우 중요한 환경에서 유용 |
| DAC(임의 접근 제어) | 리소스 소유자가 접근 권한을 부여함</br>파일 소유자가 다른 사용자에게 읽기, 쓰기 권한을 부여하거나 제거할 수 있음</br>유연성이 높지만, 보안 관리가 어려울 수 있음. |
개요
1) 제품소개 및 특장점
2) 주요 기능 구성도
- 모니터링 및 운영관리
- 멀티 클러스터 관리: 이기종 PaaS 클러스터 관리, 멀티 클러스터 통합 대시보드
- 알림설정 및 로그관리: 이벤트 및 알림관리, 감사 로그 조회
- 대시보드: 클러스터/네임스페이스 별 대시보드, 네트워크 토폴로지맵
- 서비스 카탈로그 기반 운영관리: 카탈로그 관리 및 배포, GUI 기반 서비스 프로비저닝
- DevSecOps
- CI/CD Task 관리: 빌드/배포 관리, 테스트/정적분석 관리
- 운영 대시 보드: 파이프라인 현황 조회, 파이프라인 단계별 상세 정보
- 파이프라인 관리: 내부 결재 (승인/반려), 파이프라인 로그 조회
- 보안취약점 검사: 소스코드/이미지/런타임 취약점 점검
- 컨테이너 오케스트레이션
- 파드 라이프사이클 관리: GUI 기반 기본모드/전문가 모드
- 오토 스케일링: 네임스페이스/파드 단위 리소스 쿼터 설정
- 셀프 힐링: 파드/노드 상태 모니터링, 자동 파드 생서 및 재배치
- 클러스터 자동생성 및 배포: 클러스터 자동 생성 프로세스 템플릿, 공급자연결, 네트워크 설정
- 서비스 메시기반 네트워크 트래픽 관리: 기본/마이크로서비스 기반 네트워크 트래픽 관리,컨테이너 네트워크 격리, 다양한 애플리케이션 배포 전략
- 볼륨 관리: PV/PVC 관리, 스토리지 볼륨 동적 프로비저닝
3) 제품 기능
4) 논리 구성도
5) 소프트웨어 구성주요 기능
1) 라이프사이클 관리
2) CI/CD 기능
3) 모니터링 기능
4) 네트워크
5) 보안 안정성
6) 효율성
7) 확장성 및 호환성
PV(persistence Volume), PVC(Persistence Volume Claim)
개요
쿠버네티스는 인프라에 대한 복잡성을 추상화를 통해서 간단하게 하고, 개발자들이 손쉽게 필요한 인프라(컨테이너, 디스크, 네트워크)를 설정할 수 있도록 하는 개념을 가지고 있음
그래서, 인프라의 종속적인 부분은 시스템 관리자가 설정하도록 하고, 개발자는 이에 대한 이해 없이도 간단하게 사용할 수 있도록 디스크 볼륨 부분에 PV와 PVC의 개념을 도입
- 시스템 관리자가 실제 물리 디스크를 생성한 후에 이 디스크를 PV라는 이름으로 쿠버네티스에 등록
- 개발자는 Pod는 생성할 때, 볼륨을 정의하고 이 볼륨 정의 부분에 물리적 디스크에 대한 특성을 정의하는 것이 아니라 PVC를 지정하여 관리자가 생성한 PV와 연결
PV/PVC 라이프사이클
| 단계 | 설명 |
|---|---|
| 프로비저닝(Provisioning) | yaml 파일 등을 이용해 정적(static) 또는 동적(dynamic)의 PV를 생성하는 단계</br>정적은 PV를 수동으로 생성하여 PVC에 직접 바인딩 한 후 사용하는 것</br>동적은 별도의 PV 생성 없이 PVC의 정의에 따라서 맞는 물리 디스크 생성 및 PV 생성을 자동화하는 것 |
| 바인딩(Binding) | PV를 PVC에 연결시키는 단계</br>PVC는 사용자가 요청하는 볼륨을 PV에 요청하고 PV는 그에 맞는 볼륨이 있으면 할당</br>만약 PVC가 요청하는 볼륨이 PV에 없다면 해당 요청은 무한정 남아있게 되고, PVC가 요청하는 볼륨이 PV에 생성되면 그 요청은 받아들어져 할당</br>PV와 PVC는 ClaimRef를 사용하는 1:1 관계이며 바인딩이 정상적으로 완료될 경우 bound 상태가 됨 |
| 사용(Using) | 클러스터는 PVC를 확인하여 바인딩된 PV를 찾고 해당 볼륨을 Pod에서 사용할 수 있도록 해줌</br>만약 Pod가 사용 중인 PVC를 삭제하려고 하면 Storage Object in Use Protection에 의해 삭제되지 않dma</br>만약 삭제 요청을 했다면 Pod가 PVC를 사용하지 않을 때까지 삭제 요청은 연기됨 |
| 회수(Reclamiming) | PV는 연결된 PVC가 삭제된 후 다시 다른 PVC에 의해서 재사용이 가능</br>때문에 사용이 종료된 PVC를 삭제할 때, 사용했던 PV의 데이터를 지울 지 유지할 지에 대한 정책을 Reclaim Policy를 이용하여 설정이 가능</br>- Retain: 삭제하지 않고 데이터를 유지(PV도 데이터도 모두 유지)</br>- Recycle: 재사용이 가능하며 재사용 시 데이터의 내용을 자동으로 rm -rf로 삭제한 후, 재사용 (PV만 유지, 데이터는 삭제)</br>- Delete: 사용이 종료되면 해당 볼륨은 삭제 (PV도 데이터도 모두 삭제) |
