쿠버네티스의 etcd쿠버네티스(Kubernetes)에서 etcd는 클러스터 상태를 영구적으로 저장하기 위한 분산 Key-Value 저장소임.모든 Kubernetes 오브젝트(네임스페이스, 파드, 서비스, 컨피그맵, 시크릿, RBAC, CRD 등)의 메타데이터와 상태 정보가 etcd에 저장되므로, etcd가 멈추면 쿠버네티스의 컨트롤 플레인 전체가 동작할 수 없게 됨.따라서 etcd는 쿠버네티스에서 가장 중요한 컴포넌트 중 하나임. etcd의 특징 및 아키텍처1. Key-Value 모델etcd는 key → value 형태로 데이터를 저장함.쿠버네티스의 모든 리소스 정보는 특정 경로(Key)에 직렬화된 형태(주로 JSON 등)로 저장됨.예를 들면 다음과 같음./registry/pods//, /registry..
쿠버네티스의 컨트롤플레인쿠버네티스(Kubernetes) 아키텍처에서 컨트롤 플레인(Control Plane)은 클러스터 전반의 ‘두뇌’ 역할을 수행하는 핵심 컴포넌트들의 집합임.즉, 워커 노드(Worker Node)와 파드(Pod)를 비롯한 모든 리소스를 제어하고 관리하는 중앙 집행부라고 볼 수 있음.컨트롤 플레인의 주요 목적은 클러스터 상태를 파악하고(상태 관리), 요청에 따른 적절한 자원 할당(스케줄링), 리소스의 원하는 상태(Desired State) 보장을 통해 전체 클러스터가 정상적으로 동작하도록 유지 및 관리하는 데 있음. 주요 구성 요소 : kube-apiserver1. 역할쿠버네티스의 프런트엔드(Front-end) HTTP/REST API 역할을 수행함.모든 요청(클라이언트, 내부 컴포넌트..
Flask의 AUTH_ROLES_MAPPING 및 AUTH_USER_REGISTRATION_ROLEFlask-AppBuilder(FAB)에서 사용자 등록과 역할(Role) 할당은 매우 중요한 보안·권한 관리 요소임.FAB는 다양한 인증 방식(DB, LDAP, OAuth 등)을 지원하는데, 새로운 사용자가 등록되거나 OAuth 등 외부 인증 프로바이더로부터 로그인할 때, 어떤 Role을 부여할지 정해야 함.이때 설정값인 AUTH_ROLES_MAPPING과 AUTH_USER_REGISTRATION_ROLE이 핵심적인 역할을 담당함. AUTH_ROLES_MAPPING: 외부 인증 Role → FAB Role 매핑AUTH_ROLES_MAPPING은 외부 인증 소스(OAuth Provider, LDAP 등)에서 ..
FlaskAppBuilder + Github OAuth아래는 Flask-AppBuilder(이하 FAB) 애플리케이션에서 GitHub OAuth로 로그인(인가) 연동을 구현하는 간단한 예시 코드임. 전제 조건은 다음과 같음.GitHub에서 OAuth App을 등록하여 Client ID, Client Secret을 발급받아야 함.등록 시 “Authorization callback URL”에 본인 앱의 콜백 경로를 정확히 설정해야 함.예를 들면, https://example.com/oauth-authorized/github (FAB 기본 콜백 패턴).아래 코드 예시는 최소 구성임.실제 서비스에 적용 시 데이터베이스, 권한 그룹(Role) 설정, HTTPS 구성, SECRET_KEY 보안 등 추가 설정이 필요..
OAuthOAuth(Open Authorization)은 API 보안을 위해 등장한 오픈 표준(Open Standard) 프로토콜임.사용자가 애플리케이션(클라이언트)에게 자신의 자격 증명(예: 비밀번호 등)을 직접 제공하지 않고도 제3의 서비스(리소스 서버)에 접근할 수 있도록 “권한 위임(Authorization Delegation)”을 가능하게 하는 체계임.주로 “소셜 로그인” 방식이나, 다른 플랫폼 간 데이터 공유·접근을 위임할 때 활용됨.최근에는 OAuth 2.0이 가장 널리 쓰이며, OAuth 1.0a는 이전 버전이지만 보안상의 특징 덕분에 일부 환경에서 쓰이기도 함. OAuth의 주요 개념 및 용어1. Resource Owner(리소스 소유자)사용자를 의미함.실제로 보호된 자원(Protecte..
쿠버네티스에서 롤링 업데이트쿠버네티스(Kubernetes)에서 롤링 업데이트(Rolling Update)는 애플리케이션을 중단 없이 점진적으로 새 버전(이미지, 설정 등)을 배포하는 방법을 의미함.이를 통해 서비스 가용성을 유지하면서 새로운 버전을 배포할 수 있 음. 롤링 업데이트의 기본 개념1. 점진적 배포(Gradual Deployment)기존 파드를 전부 내려버리고 새 파드를 한 번에 띄우는 방식(“빅뱅” 방식)이 아닌, 기존 파드와 새 파드를 일정 비율/순서대로 교체해 나가는 배포 방식임. 2. 무중단 서비스(Zero-downtime)최대한 “무중단(Zero-downtime)”을 지향함.기존 버전을 종료하기 전에 일부 새 버전을 먼저 올려서 트래픽을 대체하도록 함. 3. ReplicaSet / D..
쿠버네티스의 앤드포인트쿠버네티스(Kubernetes)에서 “엔드포인트(Endpoint)”는 크게 두 가지 관점에서 이해할 수 있음.1. Kubernetes 리소스로서의 Endpoints(오브젝트)2. Service가 내부적으로 관리하는 Endpoints(서비스와 파드(Pod) 간 연결 정보)둘 다 공통적으로 “Service가 라우팅해야 하는 실제 대상(주로 파드)의 IP 및 포트 정보”를 담고 있다는 점에서는 유사하지만, 쿠버네티스 API 상에서 관리되는 방법이나 동작 방식에 차이가 있음.Endpoints 오브젝트 - 정의Endpoints는 Kubernetes가 각 Service에 연결된 파드들의 네트워크 위치(주로 IP와 Port)를 추적하기 위해 생성하는 리소스임.쿠버네티스에서 Service 오브젝..
쿠버네티스 리소스 종류쿠버네티스(Kubernetes)는 클러스터 환경에서 컨테이너화된 워크로드 및 서비스를 간편하고 효율적으로 배포·운영할 수 있도록 하는 컨테이너 오케스트레이션 플랫폼임.쿠버네티스는 다양한 “리소스(자원) 유형”을 정의하여, 각각의 목적과 기능에 따라 애플리케이션 및 인프라를 구성 및 관리함. 리소스 개념1. Kubernetes Resource쿠버네티스 API에서 관리되는 모든 “객체(Object)”를 가리킴.Pod, Service, Deployment, ConfigMap, Secret 등이 대표적임. 2. 리소스 스펙(Spec)과 상태(Status)쿠버네티스 오브젝트마다 “스펙(Spec)” 필드를 통해 원하는 상태(Desired State)를 정의함.실제 시스템이 인식하는 현재 상태(..
쿠버네티스의 Secret 및 ConfigMap쿠버네티스(Kubernetes)에서 애플리케이션을 구성할 때 ConfigMap과 Secret은 매우 중요한 리소스 유형임. ConfigMap - 정의ConfigMap은 애플리케이션이 사용하는 구성(configuration) 데이터를 키-값(key-value) 쌍 형태로 저장하는 쿠버네티스 오브젝트임.예컨대 데이터베이스 연결 정보, 외부 API의 엔드포인트 주소, 환경 변수, 설정 파일 내용 등을 관리할 수 있음.ConfigMap 자체는 암호화되지 않은 일반 텍스트 형태로 데이터가 저장되므로 민감하지 않은 구성 정보에 사용하는 것을 권장함. ConfigMap - 주요 특징1. Key-Value 저장 구조data나 binaryData 필드에 JSON, YAML, ..
EKS 생성시 자동으로 생성되는 노드의 라벨Amazon EKS(Elastic Kubernetes Service)에서 매니지드 노드 그룹을 생성하거나, eksctl과 같은 툴을 사용해서 노드를 생성했을 때, 노드에는 AWS에서 자동으로 설정해주는 여러 가지 라벨(Label)이 붙음.이러한 라벨들은 크게 아래와 같은 목적을 가짐. 1. AWS 리소스 정보 노출2. 클러스터/노드 그룹 구분3. 리전/가용영역(Zone) 정보4. 쿠버네티스(및 Add-on) 스케줄링 최적화 리전(Region) 및 가용영역(Zone) 관련 라벨1. topology.kubernetes.io/region예시: topology.kubernetes.io/region=us-west-2역할: 해당 노드가 속해 있는 AWS 리전을 나타냅니다...
