Skip to content

태그: devops

총 230개의 글이 있습니다.

CDI(Container Device Interface)는 컨테이너 런타임이 GPU, FPGA 등 서드파티 디바이스를 표준화된 방식으로 지원할 수 있도록 하는 CNCF 명세이다. CNI(Container Networking Interface)의 디바이스 버전이라고 이해할 수 있다. 기존에 NVIDIA GPU를 컨테이너에서 사용하려면 NVIDIA Container Runtime이라는 전용 런타임이 필요했다. 이 런타임은 `NVIDIA_VISIBLE_DEVICES` 환경변수를 감지하여 GPU 디바이스와 드라이버 라이브러리를 컨테이너에 주입하는 방식으로 동작했다. bash 기존 방식: 환경변수 기반 docker run --runtime=nvidia -e NVIDIA_VISIBLE_DEVICES=0,1

Scheduling Framework

node-scheduling

Kubernetes Scheduling Framework는 kube-scheduler의 플러그인 기반 확장 메커니즘이다. 기존의 커스텀 스케줄링 방식들이 가진 한계를 극복하고, 유연하면서도 안정적인 확장성을 제공하기 위해 설계되었다. 등장 과정 Kubernetes에서 커스텀 스케줄링을 적용하기 위한 여러 시행착오가 있었다. Scheduler Extender 매 스케줄링마다 HTTP webhook을 호출하여 커스텀 결과를 받아오는 방식이다. 외부 서비스와의 HTTP 통신으로 인한 지연 발생 네트워크 장애 시 스케줄링 실패 가능성 Custom Scheduler 완전히 별도의 스케줄러를 띄우는 방식이다. 여러 스케줄러가 동시에 동작하면 race condition 발생 가능 따라서 Pod에 `

Debezium PostgreSQL Connector

CDC 엔진은 데이터베이스의 변경 로그를 읽어 표준화된 메시지 포맷으로 변환하는 역할을 한다. Debezium은 Kafka Connect 기반의 오픈소스 CDC 엔진 중 하나이다. Debezium PostgreSQL Connector는 PostgreSQL의 Logical Decoding을 통해 WAL(Write-Ahead Log)을 읽고, 이를 Debezium Envelope 포맷으로 변환하여 Kafka로 전송한다. INSERT, UPDATE, DELETE, TRUNCATE 작업을 실시간으로 스트리밍하며, 초기 스냅샷 기능도 제공하므로 데이터 동기화나 이벤트 소싱에 적합하다. 기본 개념 Debezium이 어떻게 PostgreSQL의 변경 데이터를 캡처하는지 이해하려면, 먼저 PostgreSQL의 핵심

Scheduling-Slides

node-scheduling

--- marp: true theme: default paginate: true backgroundColor: 1a1a2e color: eaeaea style: | section { font-family: 'Pretendard', 'Apple SD Gothic Neo', sans-serif; } h1 { color: 00d4ff; } h2 { color: 00d4ff; } code { background-color: 16213e; } strong { color: ff6b6b; } table { font-size: 0.8em; } .columns { display: grid; grid-template-col

Aurora PostgreSQL CDC with DMS

PostgreSQL은 모든 변경사항을 WAL(Write-Ahead Log)에 먼저 기록한다. 이 WAL에는 물리적 변경(어떤 페이지의 어떤 바이트가 바뀌었는지)과 논리적 변경(어떤 테이블의 어떤 row가 INSERT/UPDATE/DELETE 되었는지) 정보가 모두 담겨 있다. Logical Replication은 이 WAL에서 논리적 변경만 추출해서 외부로 스트리밍하는 기능이다. 물리적 복제와 달리 테이블 단위로 선택적 복제가 가능하고, 다른 버전의 PostgreSQL이나 아예 다른 시스템(Kafka, DMS 등)으로 데이터를 보낼 수 있다. Replication Slot 그런데 한 가지 문제가 있다. WAL은 디스크 공간을 아끼기 위해 주기적으로 삭제된다. 만약 CDC consumer가 잠시 멈춰있

EndpointSlice는 Kubernetes 1.17에서 도입된 리소스로, Service의 네트워크 엔드포인트를 확장 가능한 방식으로 추적한다. 기존 Endpoints 리소스의 확장성 한계를 극복하기 위해 설계되었으며, 현재 Kubernetes에서 Service 엔드포인트를 관리하는 기본 메커니즘이다. EndpointSlice가 왜 필요한지 이해하려면, 먼저 기존 Endpoints 리소스의 문제점을 알아야 한다. Endpoints는 하나의 오브젝트에 Service의 모든 엔드포인트를 저장한다. 예를 들어, 1000개의 Pod를 가진 Service가 있다면: yaml apiVersion: v1 kind: Endpoints metadata: name: large-service subsets:

Session Affinity

Session Affinity(세션 어피니티)는 특정 클라이언트의 요청이 항상 동일한 Pod로 라우팅되도록 하는 Kubernetes Service의 기능이다. "Sticky Session"이라고도 불리며, 상태를 유지하는 애플리케이션에서 세션 일관성을 보장하기 위해 사용한다. 기본 개념 기본적으로 Kubernetes Service는 요청을 모든 엔드포인트에 무작위로 분산한다. 이는 stateless 애플리케이션에는 문제가 없지만, 세션 상태를 메모리에 저장하는 애플리케이션에서는 문제가 된다. ┌──────────┐ ┌─────────────┐ ┌─────────┐ │ │ ──▶ │ │ ──▶ │ Pod A │ 요청 1: 로그인 (세션 생

Topology Aware Routing

Topology Aware Routing은 Kubernetes Service의 트래픽을 가능한 한 같은 Zone(가용 영역) 내의 엔드포인트로 라우팅하는 기능이다. 클러스터가 여러 Zone에 걸쳐 배포되어 있을 때, 이 기능을 활성화하면 네트워크 지연 시간을 줄이고 Zone 간 데이터 전송 비용을 절감할 수 있다. 멀티 Zone 클러스터에서 Service로 요청이 들어오면, 기본적으로 kube-proxy는 모든 엔드포인트 중 하나를 무작위로 선택한다. 이 말은 Zone A에 있는 Pod가 Zone B나 Zone C에 있는 엔드포인트로 트래픽을 보낼 수도 있다는 것이다. ┌─────────────────────────────────────────────────────────────┐ │

Linkerd와 Istio 비교

Service Mesh는 마이크로서비스 간의 통신을 관리하는 인프라 계층이다. Kubernetes 환경에서 가장 많이 사용되는 Service Mesh인 Linkerd와 Istio의 구조와 특징을 비교해보자. Service Mesh가 필요한 이유 마이크로서비스 아키텍처에서는 수십, 수백 개의 서비스가 서로 통신한다. 이때 몇 가지 문제가 발생한다. 서비스 간 통신은 기본적으로 암호화되지 않는다. 어떤 서비스가 어떤 서비스와 통신하는지 파악하기 어렵다. 특정 서비스에 장애가 발생하면 연쇄적으로 다른 서비스에 영향을 미친다. 트래픽을 세밀하게 제어하기 어렵다. 이런 문제를 해결하기 위해 각 서비스에 프록시를 붙여서 모든 트래픽을 가로채고 관리하는 방식이 등장했다. 이것이 Service Mesh다. 그

Gateway API는 Kubernetes에서 트래픽 라우팅을 관리하기 위한 차세대 API이다. 기존 Ingress의 한계를 극복하고 더 유연하고 표준화된 방식으로 L4/L7 트래픽을 관리할 수 있다. 왜 이런 변화가 필요했고, 어떤 구현체를 선택해야 할지 알아보자. Ingress의 한계 Ingress는 오랫동안 Kubernetes에서 외부 트래픽을 내부 서비스로 라우팅하는 표준이었다. 하지만 사용하다 보면 몇 가지 문제를 마주하게 된다. 프로토콜 제약 Ingress는 HTTP/HTTPS만 지원한다. TCP나 UDP 트래픽을 라우팅하려면 별도의 Service를 NodePort나 LoadBalancer로 노출해야 한다. gRPC도 직접적으로 지원하지 않는다. 어노테이션 지옥 Ing

Dex는 OpenID Connect를 사용하여 다른 애플리케이션의 인증을 처리하는 identity service이다. Dex는 다른 identity provider로의 커넥터 역할을 한다. Dex는 LDAP 서버, SAML provider, GitHub, Google, Active Directory와 같은 기존 identity provider에게 인증을 위임할 수 있다. 클라이언트가 Dex와 통신하기 위한 인증 로직을 한 번만 작성하면, Dex가 각 백엔드에 대한 프로토콜을 처리한다. ID Tokens ID Token은 OpenID Connect에서 도입된 OAuth2 확장 기능이며 Dex의 핵심 기능이다. ID Token은 Dex가 서명한 JSON Web Token(JWT)으로, OAuth2 응답

Keycloak과 인가(Authorization)을 쉽게 해주고 SSO(Single-Sign-On)을 가능하게 해주는 오픈소스이다. SSO란? SSO는 Single-Sign-On의 약자로 한번의 로그인을 통해 그와 연결된 여러가지 다른 사이트들을 자동으로 접속하여 이용할 수 있도록 하는 방법이다. 일반적으로는 여러 사이트를 사용할 떄 각각의 DB에 각각의 사용자 정보가 있고 그 정보를 통해서 관리를 하게 되는데, 필요에 따라서는 사용자 정보를 연동하여 사용해야 하는 경우가 발생한다. 이런 경우에 SSO 기능을 사용하게 되며 하나의 시스템에서 인증을 할 경우 그와 연결된 다른

secrets-management

HashiCorp Vault is an identity-based secrets and encryption management system. A secret is anything that you want to tightly control access to, such as API encryption keys, passwords, and certificates. Vault provides encryption services that are gated by authentication and authorization methods. Using Vault’s UI, CLI, or HTTP API, access to secrets and other sensitive data can be securely store

Karpenter best practices

Use Karpenter for workloads with changing capacity needs karpenter brings scailing management closer to Kubernetes native APIs than do Autoscaling Groups and Managed Node Groups. ASGs and MNGs are AWS-native

큐 메세지 갯수 등 지정한 메트릭에 따라 스케일링하기 위해 사용 SacaledObject yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: demo namespace: inflearn spec: scaleTargetRef: name: demo apiVersion: {api-version-of-target-resource} Optional. Default: apps/v1 kind: {kind-of-target-resource} Optional. Default: Deployment triggers: type: aws-sqs-qu

node-scheduling

k8s Scheduler의 동작 Pod를 정의하면 그 Pod를 정의할 수 있는 적절한 Node를 찾아서 배치해줌. 적절한 Node는 selector, taint & toleration, priority 등 설정값에 따라 정함 그리고 nodeName에 node 이름을 추가해줌 만약 nodeName을 지정하여 생성하면 스케줄 동작 없이 직접 원하는 노드에 바로 스케줄링함 yaml apiVersion: v1 kind: Pod metadata: name: ... spec: containers: ... nodeSelector: type: hello nodeName: ip-10-12-34-56.ap-northeast-2.compute.internal --- 스케줄러

PLEG PLEG is part of kubelet and stands for Pod Lifecycle Event Generator In Kubernetes, Kubelet is a per-node daemon that manages the pods on the node, driving the pod states to match their pod specifications (specs). To achieve this, Kubelet needs to react to changes in both (1) pod specs and (2) the container states. For the former, Kubelet watches the pod specs changes from multiple sour

Prometheus는 강력한 모니터링 및 알림 시스템이지만, 유연성이 높은만큼 사전 구성(configuration)이 많이 필요하다. 이에 따라 어떤 애플리케이션에 대한 모니터링을 쉽게 설정할 수 있도록 묶어놓은 것이 Mixin이다. 예시 목적 및 목표 Monitoring Mixins는 다음과 같은 특성을 가지는 구성 단위이다: 1. 플랫폼 중립성: Kubernetes 외에도 다양한 환경에서 쉽게 설치할 수 있어야 한다. 2. 애플리케이션과 함께 배포: 해당 애플리케이션 개발자가 직접 정의하거나 함께 배포할 수 있도록. 3. 협업 및 진화 가능성: 사용자 정의를 복사해서 사용하는 대신, 원본에 기여하거나 버전 업그레이드가 가능한 구조. 4. 재사용성과 구성 가능성

Argo Workflow Priority

1. Controller에서 Priority 추출 (controller.go (int32, time.Time) { un, ok := obj.(*unstructured.Unstructured) if !ok { return 0, time.Now() } priority, hasPriority, err := unstructured.NestedInt64(un.O

Control Plane Control plane은 Kubernetes의 전용 네임스페이스 (`linkerd`)에서 Linkerd 전체 제어를 위해 실행되는 서비스 집합이다. Destination Service 프록시가 서비스 디스커버리 정보를 가져오는 역할 서비스가 어디에 있는지, 어떤 TLS 인증서가 필요한지 등의 정보를 gRPC API로 제공 정책 정보와 service profile(재시도, 타임아웃, per-route metrics에 사용)을 프록시에 전달 Identity Service mTLS를 위한 인증서 발급 기능을 수행 프록시가 부트스트랩 시 CSR(Certificate Signing Request)을 보내면, CA 역할을 하여 서명된 인증서를 반환 프록시 간 통신

Mimir out-of-order sample ingestion

1. Ingestion 단계 Prometheus TSDB는 Head Block이라는 메모리 상의 데이터 구조를 갖고 있으며, 일반적으로는 여기에 in-order 샘플을 압축 형태로 저장한다. 최대 120개의 샘플이 하나의 압축 청크로 관리된다. Grafana Mimir는 이 Head Block을 공유하여 메모리 사용량을 줄이고, 동시에 out-of-order 샘플도 함께 저장할 수 있도록 설계했다. OOO(Out-of-Order) 샘플은 in-order 샘플과 격리된 영역에 비압축 상태로 메모리에 저장되며, 최대 30개까지 허용된다. 이는 압축이 되지 않은 채로 유지되므로 메모리 사용량을 제어하기 위함이다. 만약 샘플이 in-order인지 아닌지를 ingesti

Mimir와 Cortex

Cortex와 Mimir는 Prometheus의 확장성과 장기 저장 한계를 극복하기 위해 설계된 오픈소스 시계열 데이터베이스이다. Cortex Cortex는 Cloud Native Computing Foundation(CNCF)의 인큐베이팅 프로젝트로, 커뮤니티 중심의 개발이 이루어진다. Amazon DynamoDB, Google Bigtable, Apache Cassandra 등 다양한 백엔드 저장소를 지원한다. 수평 확장이 가능하며, 데이터 복제를 통해 고가용성을 제공한다. 여러 테넌트의 데이터를 분리하여 저장하고 쿼리할 수 있다. Mimir Mimir는 Cortex에서 분기되어 Grafana Labs에 의해 개발되었으며, Cortex의 복잡성을 줄이고 성능을 향상시키는 데 중점을 두었다. 모

Bloom Filter는 1970년 Burton Howard Bloom에 의해 고안된 공간 효율적인 확률적 데이터 구조로서, 어떤 요소가 집합에 속하는지를 테스트하는 데 사용된다. 이 구조의 핵심적인 특징은 false positive가 발생할 수 있지만, false negative는 발생하지 않는다는 점이다. 즉, Bloom Filter는 주어진 쿼리에 대해 "집합에 포함되어 있을 수도 있음" 또는 "집합에 확실히 포함되어 있지 않음" 중 하나의 결과를 반환한다. 충분한 메모리가 있다면 오류 없는 인덱스 해시를 사용할 수 있지만, 메모리가 제한적일 경우 Bloom Filter를 사용하는 것 만으로도 대부분의 디스크 접근을 불필요하게 만들 수 있다. Bloom Filter는 add only이고, 삭제 기능이

What is DeepFlow DeepFlow is an observability product, designed to provide in-depth observability for complex cloud infrastructure and cloud-native application. Based on eBPF, DeepFlow implements application performance metrics, distributed tracing, continuous profiling, and other observation signals with zero-disturbance (Zero Code) collection, integrating intelligent tags (SmartE

DeepFlow 논문 요약

DeepFlow는 복잡한 클라우드 인프라와 클라우드 네이티브 애플리케이션에 대한 심층 관찰성을 제공하도록 설계된 observability product 이다. Network-Centric Tracing Plane ingress-egress와 enter-exit 두 가지 함수 세트를 가진 narrow-waist instrumentation 모델 DeepFlow는 10개의 시스템 콜 ABI를 계측하고 이를 ingress 또는 egress로 분류한다. DeepFlow는 각 ingress 또는 egress 호출이 커널에 들어가거나(enter) 나올 때(exit) 정보를 저장한다. 유저 공간에서 추가 처리를 위해 네 가지 범주의 정보가 기록된다: 1. 프로그램 정보: 프로세스 ID, 스레드 ID, 코

Gorilla Compression

Gorilla Compression에서 널리 활용된다. 아래 프로그램에도 Gorilla Compression에서 착안되었거나 유사한 압축 로직이 사용되고 있다. Prometheus: time series chunk compression에서 유사한 기법 채택 InfluxDB: TSM(Time Structured Merge tree) 엔진에 유사한 delta/

victoria-metrics

Loki는 Grafana에서 개발한 오픈소스 로그 관리 시스템이며, Elasticsearch나 OpenSearch 같은 기존의 오픈소스 로그 데이터베이스보다 RAM과 저장 공간을 적게 사용하는 것이 주요 장점이다. Loki는 전체 로그를 인덱싱하지 않고, 일부 로그 필드(로그 스트림 라벨)만 인덱싱하는 구조이기 때문에, 빠른 전체 텍스트 검색은 지원하지 않지만 라벨을 통한 빠른 로그 스트림 탐색은 가능하다. 로그를 압축 저장함으로써 저장 공간 효율이 높아지고, 이러한 아키텍처는 대량 로그 저장과 분석에 필요한 CPU, RAM, 스토리지 등의 인프라 비용을 절감할 수 있게 해준다. 그러나 Loki는 Elasticsearch와 비교했을 때 다음과 같은 단점을 가진다. 관리 측면 Loki는 구성

CloudWatch 로그 기능: 하위 개념 Log Group Log Stream S3](

ASG Lifecycle Hook

ASG를 통해 생성되는 인스턴스들은 아래와 같은 Lifecycle을 가지고 있다. ASG가 인스턴스를 증가시키는 이벤트는 Scale out 이벤트이며, 이 때는 `Pending` 상태가 된다. 인스턴스가 부트스트랩 과정을 마치고 나면 `InService` 상태가 된다. 인스턴스가 축소되는 이벤트는 Scale in 이벤트이며, `Terminating` 상태를 거쳐 `Terminated` 상태가 된다. ASG의 Lifecycle Hook은 이 과정 중 Scale in과 Scale out 과정에 설정할 수 있다. 먼저 Scale out 이벤트에 걸게 된다면 인스턴스는 `Pending` 이후에 `Pending:Wait` 상태와 `Pending:Proceed` 상태를 거치게 되고, Scale in 이벤트에

AWS Instance Store는 Amazon Elastic Compute Cloud (EC2)에서 제공하는 임시 블록 수준 스토리지 서비스이다. EC2 인스턴스에 직접 연결된 로컬 디스크로, EC2 인스턴스가 실행 중인 동안에만 데이터를 유지한다. Instance Store는 인스턴스와 함께 묶여 있어 저렴하면서도 빠른 I/O 처리량을 제공한다. 그러므로 인스턴스 스토어를 사용하여 저지연 및 높은 처리량 작업을 수행할 수 있다. (대규모 데이터베이스, 데이터 웨어하우스, 로그 분석, 캐싱 등) 하지만 Instance Store는 휘발성이므로, 인스턴스가 종료되거나 재부팅되면 데이터가 영구적으로 삭제된다. 그러므로 임시 데이터나 캐시와 같이 데이터의 지속성이 필요하지 않은 작업에 적합하다. AWS I

RI와 Saving plan

RI 예약 인스턴스(Reserved Instance)라고 한다. 1년 혹은 3년 동안 EC2 혹은 RDS 인스턴스의 특정 유형을 예약하여 사용하는 방법이다. 예를 들어, `t2.micro` 인스턴스 3개를 1년치 예약한다고 하자. 그럼 1년 동안은 실행 중인 t2.micro 인스턴스 3개에 대해 추가 비용 없이 사용할 수 있다(이미 비용을 지불했기 때문). 즉, 기존 t2.micro 인스턴스를 삭제하고 새로운 t2.micro 인스턴스를 생성해도 새로운 인스턴스는 자동으로 예약 인스턴스에 포함된다. 예약 인스턴스는 3가지 결제 방식을 지원한다. 1. 전체 선결제(All Upfront) 비용을 모두 선결제, 가장 저렴하다. 2. 부분 선결제(Partial Upfront) 일부는 선결제, 일부는 선결

Fault Injection Semulator

AWS Fault Injection Simulator는 AWS에서 오류 주입 실험을 실행하기 위한 서비스로서 부하가 있을 때의 성능 테스트나, 특정 실패 이벤트에 대한 대처를 시뮬레이션해볼 수 있도록 한다. 테스트 결과를 통해 애플리케이션의 성능과 복원력을 개선시켜 애플리케이션이 예상대로 작동하도록 만들 수 있다. 실제 AWS 리소스에 대해 작업을 수행하기 때문에, 아무런 대비 없이 FIS를 돌리는 것은 서버 공격이나 다름없다. 꼭 자동 복구 작업 세팅 후 테스트하기 위해서 사용하자. Target으로 사용할 수 있는 서비스 목록 Amazon CloudWatch Amazon EBS Amazon EC2 Amazon ECS Amazon EKS Amazon RDS AWS Systems Manager S

NAT gateway & NAT instance

|속성| NAT 게이트웨이|NAT 인스턴스| |-|-|-| |가용성| 고가용성. 각 가용 영역의 NAT 게이트웨이는 중복적으로 구현됩니다. 각 가용 영역에 하나의 NAT 게이트웨이를 만들어 아키텍처가 영역에 종속되지 않도록 한다. |스크립트를 사용하여 인스턴스 간의 장애 조치를 관리한다.| |대역폭| 최대 100Gbps까지 확장한다.|인스턴스 유형의 대역폭에 따라 다르다.| |유지 관리| AWS에서 관리한다. 유지 관리 작업을 수행할 필요가 없다.|사용자가 관리한다(예: 인스턴스에 소프트웨어 업데이트 또는 운영 체제 패치 설치).| |성능| 소프트웨어가 NAT 트래픽 처리에 최적화되어 있다. |NAT를 수행하도록 구성된 일반 AMI입니다.| |비용| 사용하는 NAT 게이트웨이 수, 사용 기간, NAT 게이트

!image는 퍼블릭 클라우드 내에서 호스팅되는 안전하고 격리된 프라이빗 클라우드이다. VPC를 사용하면 정의한 논리적으로 격리된 가상 네트워크에서 AWS 리소스를 효율적으로 관리할 수 있다. VPC별로 네트워크를 구성하거나 각각의 VPC에 따라 다르게 네트워크 설정을 줄 수 있다. 또한 각각의 VPC는 완전히 독립된 네트워크처럼 작동한다. 아래 그림은 VPC의 예시이다. VPC에는 리전의 각 가용성 영역에 하나의 서브넷이 있고, 각 서브넷에 EC2 인스턴스가 있고, VPC의 리소스와 인터넷 간의 통신을 허

VPC Mapping Service

AWS VPC를 이용해서 가상 네트워크를 만들면 아래와 같은 구성이 된다. 물리 Host 내에 다수의 VPC가 존재할 수 있고, 각 VPC 간에는 독립적인 구성이 가능하다. 각 VPC는 서로 다른 IP 대역(CIDR)를 사용하는 것 뿐 아니라, 내부 IP를 같은 값으로 지정할 수도 있다. 하나의 VPC는 여러 물리 Host로 나뉘어 위치하기도 한다. 서로 다른 Host에 위치한 `ZIGI-VM1`과 `ZIGI-VM3`은 논리적으로 같은 네트워크이기 때문에 서로 간의 통신이 가능하다. 근데 물리적으로 서로 다른 `ZIGI-VPC1`과 `ZIGI-VM3`은 어떻게 통신이 가능할까? 바로 아래과 같이 VPC에 대한 정보는 Encapsulation하고, 통신하고자 하는 물리 Host IP 정보를 같이 담

AWS Site-to-Site VPN You can create an IPsec VPN connection between your VPC and your remote network. On the AWS side of the Site-to-Site VPN connection, a virtual private gateway or transit gateway provides two VPN endpoints (tunnels) for automatic failover. You configure your customer gateway device on the remote side of the Site-to-Site VPN connection. For more information, see the AWS Site-t

AWS 리소스 구성 후 관리자는 VPC 외부에서 Private Subnet에 직접 접근할 수 없다. Private Subnet의 Private한 특성을 지키기 위해 Public Subnet인 인스턴스를 하나 만들어서 그 인스턴스를 통해 접근하는 방법을 많이 쓰는데, 이러한 host를 Bastion Host라고 부른다. 쉽게 말하면 내부와 외부 네트워크 사이에서 일종의 게이트 역할을 수행하는 호스트이다. 관리자가 Bastion Host으로 SSH 연결을 한 후 Bastion Host에서 Private Subnet의 Host에 SSH 연결을 하는 형태로 Private Subnet에 접근할 수 있다. SSH 연결을 수행해야 하기 때문에 Bastion Host 또한 Public Subnet에 위치하는 EC2

Endpoints는 Service가 트래픽을 보낼 대상 Pod들의 IP와 포트 정보를 저장하는 리소스다. Service를 생성하면 어떻게 될까? `selector`에 매칭되는 Pod들을 찾아서, 그 Pod들의 IP 주소를 Endpoints 오브젝트에 자동으로 등록한다. kube-proxy는 이 Endpoints를 보고 iptables/IPVS 규칙을 만들어 실제 트래픽을 라우팅한다. yaml apiVersion: v1 kind: Endpoints metadata: name: my-service subsets: addresses: ip: 10.0.0.1 ip: 10.0.0.2 ports: port: 80 위 Endpoints는 `my-servic

buildx load 옵션

Docker의 고급 빌드 도구인 `buildx`는 멀티 플랫폼 지원과 빌드 캐시 최적화 기능 등 다양한 장점을 제공한다. 그러나 빌드 결과가 로컬에 저장되지 않거나 푸시되지 않는 문제가 발생할 수 있다. 이는 `--load` 또는 `--push` 옵션을 명시하지 않았기 때문이다. 예시 bash docker buildx build --platform linux/amd64 -t subtitle-generator . 빌드는 성공하지만 `--load`나 `--push` 옵션이 없어서 결과 이미지가 로컬에 존재하지 않는다 빌드 로그에는 다음과 같은 경고가 나타난다. WARNING: No output specified with docker-container driver. Build res

sh 기본 kubeconfig 사용 $ k9s 기본이 아닌 kubeconfig 사용 $ k9s --kubeconfig /path/to/kubeconfig 기본이 아닌 context 사용 $ k9s --context fooctx 읽기 전용 모드 $ k9s --readonly 정보 확인 (설정, 로그, 화면 덤프 위치) $ k9s info 리소스 목록 조회 특정 리소스 목록 조회: :: 리소스 목록 조회, 예: 모든 Pod 목록 조회하려면 :pod : : 특정 네임스페이스의 리소스 목록 조회 사용 가능한 모든 리소스/API 목록 조회: :aliases 또는 Ctrl-a: 사용 가능한 모든 별칭과 리소스 목록 조회 :

ArgoCD application을 모아서 관리하는 패턴을 `App of Apps` 패턴이라고 한다. app of app 패턴으로 구성된 application을 sync하면 여러 argoCD application을 생성하고, 생성된 application은 바라보는 git에 저장된 쿠버네티스 리소스를 배포한다. 상위 앱이 하위 앱을 여러개 정의하는 구조라고 보면 된다. 공식 레포에 있는 예제를 살펴보자. ( yml ├── Chart.yaml ├── templates │ ├── guestbook.yaml │ ├── helm-dependency.yaml │ ├── helm-

출처: ArhoCD, ArgCD CLI 설치 Argo CD를 kubernetes cluster에 설치한다. yml $ kubectl create namespace argocd $ kubectl apply -n argocd -f Argo CD의 CLI를 설치한다. yml $ curl -sSL -o ~/bin/argocd

Config Management Plugins

Argo CD allows us to integrate more config management tools using config management plugins. Most prominent inbuilt tools are helm and kustomize. We have to option, when it comes to create our own Config Management Plugin (CMP): Add the plugin config to the main Argo CD ConfigMap. Our repo-server container will then run the plugin's commands. There are two ways to install a Config Management Pl

datadog anomaly detection algorithms

Datadog은 Anormaly detection 기준 설정을 위해 최대 6주간의 데이터를 학습하고, 아래 세 알고리즘 중 하나에 따라 계산한다. Basic (기본) 반복적인 계절성 패턴이 없는 지표에 사용한다. 간단한 롤링 윈도우 분위수 계산으로 예상 값의 범위를 결정한다. 적은 양의 데이터를 사용하고 변화하는 조건에 빠르게 적응하지만, 계절적 동작이나 장기 추세를 반영할 수 없다. Agile (민첩) 계절성이 있고 변동이 예상되는 지표에 사용한다. 이 알고리즘은 지표 수준의 변화에 빠르게 적응한다. [SARIMA]( 알고리즘의 견고한 버전으로, 직전의 과거 데이터를 예

Jenkins FileSystem .jenkins: The default Jenkins home directory (may be .hudson in older installations). fingerprints: This directory is used by Jenkins to keep track of artifact fingerprints. We look at how to track artifacts later on in the book. jobs: This directory contains configuration details about the build jobs that Jenkins manages, as well as the artifacts and data resulting from

SSL passthrough

Only way to have ssl passthrough is by using a stream host. And Nginx can't run a stream on the same port as other proxies. It's one stream per port, and a port with a stream attached can't have any other proxies attached. We can work around this by routing all HTTPS traffic through this single stream, which in turn forwards it either to the ssl passthrough server or back to nginx itself on a

CUE는 논리 프로그래밍에 기반을 둔 오픈소스 데이터 검증 언어 및 추론 엔진이다. 이 언어는 데이터 검증, 템플릿 작성, 구성 관리, 쿼리 실행, 코드 생성, 스크립팅 등 다양한 용도로 사용될 수 있다. CUE의 추론 엔진은 코드 내에서 데이터를 검증하거나 코드 생성 파이프라인의 일부로 활용될 수 있어 유연성이 높다. JSON의 슈퍼셋이기 때문에 json과 비슷하게 사용할 수 있고, json이나 yaml로 export하는 것도 가능하다. json // json.cue one: 1 two: 2 // A field using quotes. "two-and-a-half": 2.5 list: [ 1, 2, 3, ] json $ cue export json.cue {

SLA: Service Level Agreements SLA는 고객이 서비스를 사용할 때 기대하는 서비스 레벨이다. SLA를 정의할 떄는 단순한 지표를 사용하는 것이 좋다. SLO: Service Level Objectives SLO란 시스템에서 기대하는 가용성을 설정한 목표이다. SLA가 사용자가 기대하는 수치라면, SLO는 실제로 팀에서 지키기 위해 노력할 달성 목표이다. SLO는 발생할 수 있는 변수를 감안하여 SLA보다 더 높은 값으로 설정하는 경우가 많다. 목표에 집중하기 위해선 SLO는 최소 갯수만 정의하는 것이 좋다. SLI: Service Level Indicator SLI란 사용자가 시스템의 가용성을 경험하는 방식을 정량적으로 측정한 것이다. 즉, 목

GoCD는 CI/CD(지속적 배포-Continuous Delivery) 파이프라인을 쉽게 모델링 및 시각화할 수 있도록 해주는 툴이다. 젠킨스처럼 다양한 플러그인을 지원하지는 않지만, 파이프라인 요청에 따라 클러스터에서 적절한 리소스를 할당해 실해주는 Ad-Hoc 환경을 지원해주기 때문에 클라우드 환경에 좀더 적합할 수 있다. 실습 설치 helm으로 빠르게 깔아보자 helm repo add gocd helm repo update helm install gocd gocd/gocd --namespace gocd --create-namespace 파이프라인 수정 처음 들어가면 getting_started_pipeline

MetalLB는 BareMetal LoadBalancer의 약자로, Kubernetes 클러스터에 연결되어 온프레미스 환경(IDC)에서 로드밸런서 타입 서비스를 구현해주는 툴이다. MetalLB가 제공하는 기능을 크게 나누면 주소를 할당해주는 기능과 외부와 연결하는 기능 두 가지로 나누어 볼 수 있다. 주소 할당 클라우드 제공업체의 Kubernetes 클러스터에서는 로드밸런서를 요청하면 클라우드 플랫폼이 IP 주소를 할당해준다. 베어메탈 클러스터에서는 MetalLB가 이 할당을 담당한다. MetalLB에 사용할 수 있는 IP 주소 풀을 제공하면 해당 풀에서 LB를 생성해준다. 외부 연결 MetalLB가 서비스에 외부 IP 주소를 할당한 후에는 해당 IP가 클러스터에 "존재한다"는 것을 클러스터 외

AWS Organization

AWS Organization는 AWS 계정 (accounts)을 단일 단위로 통합해 관리할 수 있는 개체이다. Organization 안의 모든 계정을 중앙에서 확인하고 관리할 수 있다. AWS Organizations는 비즈니스의 예산, 보안과 규정 준수 필요 충족에 도움이 되는 계정 관리 및 통합 결제 기능까지 함께 제공한다. 조직의 관리자로서 조직에서 계정을 생성하고 기존 계정을 조직에 초대할 수 있다. 1개의 관리자 계정(management account)과 0개 이상의 멤버 계정(member account)을 갖고 있다. 위 그림에 나타나 있듯이 tree 계층 구조로 OU를 생성할 수 있다. 각 계정(Each Account)을 OU에 포함하거나 루트에 포함할 수 있다. 루트 (Root)

Pyroscope Distributor and Ingester

Distributor Distributor는 Agent로부터 프로파일링 데이터를 받아 처리하는 Stateless 컴포넌트이다. Distributor는 데이터를 일괄 처리하여 여러 Ingesters에 병렬로 보내고, 시리즈를 Ingesters 사이에 나누며, 각 시리즈를 구성된 복제 요소에 따라 복제한다. 기본적으로 구성된 복제 요소는 세 개이다. 유효성 검사 Distributor는 데이터를 Ingester에 전달하기 전에 유효성을 검사, 변환 절차를 거친다. 데이터 중 일부 샘플만 유효하다면 유효한 데이터만 Ingester에 전달하고, 유효하지 않은 데이터는 Ingesters에 보내지지 않는다. 요청에 유효하지 않은 데이터가 포함되어 있으면 Distributor는 Bad Reques

AWS 2024 Summit Seoul

2024/05/16(목) AWS Summit 데이터 처리도 이제는 컨테이너로, 우아한 형제들의 데이터 플랫폼 혁신 컨테이너로 데이터 처리하기 데이터 처리의 어려움 인프라 구성 다양한 데이터 포맷, 프레임워크 급격한 데이터량 증가 빠르게 변화하는 비즈니스 컨테이너와 데이터 처리를 결합한다면? 이미지 기반으로 쉽게 패키징할 수 있음 컴퓨팅 작업을 빠르고 유연하게 확보할 수 있음 대표적인 방법: EMR on EKS 특징 하나의 EMR 워크로드를 다수의 Pod로 구성 EKS 워크로드에 필요한 코드, 라이브러리, 프레임워크를 컨테이너 이미지에 내장 EMRFS/S3를 데이터 저장소로 활용 Spark, Flink 지원 장점 빠르고 유연한 컴

Platform Engineering

플랫폼 엔지니어링은 클라우드 네이티브 시대에 소프트웨어 엔지니어링 조직의 작업을 촉진하고 가속화하기 위한 플랫폼을 설계하고 제공하는 분야이다. 다시 말해, 플랫폼 엔지니어링의 목적은 "소프트웨어 엔지니어링 조직이 일을 더 빠르게 잘 할 수 있도록 하는 것"이고, 그 문제를 "플랫폼"을 통해 해결한다. 애플리케이션을 빠르게 제공할 수 있도록 지원하는 DevOps와도 비슷한 목적을 가지고 있다. 개발과 운영 조직의 비효율성을 문화와 도구들을 이용해 해결하려는게 DevOps라면, 플랫폼 엔지니어링은 DevOps의 도구로 '플랫폼'을 채택한 것이라는 차이가 있다. 플랫폼 엔지니어링 팀은 DevOps 방법론 위에서 소프트웨어 엔지니어링 팀, 프로덕트 팀을 지원할 수 있는 플랫폼을 만든다. 플랫폼 엔지니어링은 아

1. 배경 Linux 신호는 컨테이너 내부의 프로세스 수명 주기를 제어하는 주요 방법이다. 앱의 수명 주기를 앱이 포함된 컨테이너와 긴밀하게 연결하려면 앱이 Linux 신호를 올바르게 처리하도록 해야한다. 프로세스 식별자(PID)는 Linux커널이 각 프로세스에 제공하는 고유한 식별자이다. PID는 namespace다. 즉, 컨테이너에는 호스트 시스템의 PID가 매핑되는 고유한 PID 세트가 있다. Linux 커널을 시작할 때 실행된 첫 번째 프로세스에는 PID 1이 있다. 정상적인 운영체제의 경우 이 프로세스는 init 시스템(ex. systemd 또는 SysV)이다. 마찬가지로 컨테이너에서 실행된 첫 번째 프로세스는 PID 1을 얻는다. Docker와 Kubernetes는 신호를 사용하여 컨테이

SAA 오답노트

The founder has provisioned an EC2 instance 1A which is running in region A. Later, he takes a snapshot of the instance 1A and then creates a new AMI in region A from this snapshot. This AMI is then copied into another region B. The founder provisions an instance 1B in region B using this new AMI in region B. At this point in time, what entities exist in region B? Keyword: AMI Answer: 1 EC2

Grafana Agent is an OpenTelemetry Collector distribution with configuration. It is designed to be flexible, performant, and compatible with multiple ecosystems such as Prometheus and OpenTelemetry. Grafana Agent is based around components. Components are wired together to form programmable observability pipelines for telemetry collection, processing, and delivery. Grafana Agent is availa

Metrics Server is a scalable, efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines. K8s *메트릭 API(Metrics API)* 는 자동 스케일링 및 비슷한 사용 사례를 지원하기 위한 기본적인 메트릭 집합을 제공한다. 이 API를 사용해 노드와 파드의 CPU 및 메모리 사용량을 쉽게 쿼리할 수 있다. (`kubectl top [HorizontalPodAutoscaler](

Amazon Athena는 오픈 소스 프레임워크를 기반으로 구축된 서버리스 대화형 분석 서비스로, 오픈 테이블 및 파일 형식을 지원한다. 페타바이트 규모의 데이터를 분석할 수 있는 간단한 방법을 제공한다. Athena를 사용하면 SQL 또는 Python을 사용하여 Amazon Simple Storage Service(S3) 데이터 레이크와 온프레미스 데이터 소스나 다른 클라우드 시스템을 포함한 30개의 데이터 소스에서 데이터를 분석하거나 애플리케이션을 구축할 수 있다. 오픈 소스 Trino 및 Presto 엔진과 Apache Spark 프레임워크를 기반으로 구축되어 있으며, 프로비저닝이나 구성 작업 없이 사용할 수 있다. SQL용 Amazon Athena는 AWS Management Consol

API Gateway is a fully managed service for developers that makes it easy to build, publish, manage, and secure entire APIs. With a few clicks in the AWS Management Console, you can create an API that acts as a “front door” for applications to access data, business logic, or functionality from your back-end services, such as workloads running on EC2 code running on AWS Lambda, or any web applicatio

AWS cloud computing

In 2006, Amazon Web Services(AWS) began offering IT infrastructure services(cloud computing). Ont of the key benefits of cloud computing is the opportunity to replace upfront capital infrastructure expenses with low variable costs that scale with your business. With the cloud, businesses no longer need to plan for and procuure servers and other IT infrastructure weeks or month in advance. Instead,

Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service that helps you easily deploy, manage, and scale containerized applications. As a fully managed service, Amazon ECS comes with AWS configuration and operational best practices built-in. It's integrated with both AWS and third-party tools, such as Amazon Elastic Container Registry and Docker. This integr

Lambda 제약사항 문서 배포 배포 패키지 크기 콘솔 직접 업로드·API: ~50MB S3에 업로드: ~250MB 컨테이너 배포 크기 ~10GB (모든 레이어를 포함한 최대 비압축 이미지 크기) 요청 및 응답 크기 동기식: 요청/응답 모두 ~6MB 스트리밍 동기식 응답: ~200MB (2MBps 대역폭 지원) 비동기식: ~1MB 동

AWS resouce는 전세계의 여러 위치에서 호스팅되고 있다. 그리고 내부적으로도 여러 영역으로 나뉘어있다. 그 중 Availability Zone, Local Zone, Wavelength Zones에 대해 알아보자. ![image]( Availability Zone ![image]( 각 Region에는 Availability Zone이라고 하는 여러 개의 격리된 위치가

Analytics QuickSight: Visualization Compute EC2: Elastic Compute Cloud 종류 On-Demand instances: 서버 대여, 시간 당 지불 Reserved instance: 1~3년간 대여 Spot instances: 사용자 제시 가격(입찰가격)을 정해놓고 저렴할 때 이용 placement default partition: 대규모 분산 및 복제 워크로드 cluster: HPC API Gateway: REST 및 Websocker API를 생성, 유지, 관리 Datab

KMS는 Key Management Service의 약자로, 데이터를 암호화 할떄 사용되는 암호화 Key를 안전하게 관리하는데 목적을 둔 AWS의 서비스이다. KMS는 크게 세가지 방식으로 key 관리 서비스를 제공한다. AWS managed key AWS 서비스들이 내부적으로 발급받는 Key로, 내부적으로 자동으로 일어나게 되며 사용자가 직접적으로 제어가 불가능하다. 자신의 AWS 계정에 들어가면 만들어진 Key의 목록을 확인하는건 가능하다. [(참고)]( 모든 AWS managed keys는 1년마다 rotate된다. 이 주기는 사용자가 변경할 수 없다. Cust

Well Architected

AWS provide [Well-Architecture Framework]( to build a secure, high-performance, resilient and efficient infrastructure for a wide variety of appl

CI／CD파이프라인

CI(Continuous Integration) CI는 지속적 통합이라는 뜻으로 여러 명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 충돌 없이 작업, 관리할 수 있음을 의미한다. 또한, 공유 버전 관리 레포지토리에 통합되어 있는 코드에 대해, 자동화된 테스트를 진행하여 통합된 코드에서 생기는 문제를 신속하게 파악하고 해결할 수 있도록 하는 것이 CI의 특징이다. CD(Continuous Delivery/Deployment) CD는 지속적인 제공또는 지속적인 배포를 모두 의미한다. 두 가지 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만, 자세한 개념은 다르다. 지속적인 제공(Continuous Delivery) 지속적인 제공은 개발자들이 애플리케이션에 적용한 변경사항이 버그

Cloud Agnostic Design

Agnostic is a term that refers to a kind of belief that does not determine the authenticity of religion, but it is often used in an extended sense in many fields. When it's commonly used, it means that you're not tied to a particular idea, concept, or theory. It's same to Cloud Agnostic. Storage, compute, and networking are at the heart of any cloud infrastructure. In addition, managed, unmanage

Kubernetes(k8s)에서 cAdvisor는 "Container Advisor"의 줄임말로, 컨테이너 메트릭을 수집하고 모니터링하기 위한 도구이다. cAdvisor는 Google에서 개발한 오픈 소스 프로젝트로, 컨테이너화된 환경에서 작동하는 애플리케이션 및 서비스의 성능을 실시간으로 추적하고 이해하는 데 도움을 준다. 주 기능 컨테이너 메트릭 수집: cAdvisor는 호스트 시스템에서 실행 중인 각 컨테이너에 대한 메트릭을 수집한다. 이 메트릭은 CPU 사용량, 메모리 사용량, 디스크 I/O, 네트워크 사용량 및 다른 성능 관련 정보를 포함한다. 시각화: cAdvisor는 수집된 메트릭을 시각적으로 표시하여 사용자가 컨테이너의 성능과 리소스 사용 상태를 쉽게 이해할 수 있도록 도와

Calico는 Kubernetes 기반 워크로드와 비-Kubernetes 또는 레거시 워크로드 간의 안전하고 원활한 통신을 가능하게 하는 네트워크 및 보안 솔루션이다. Kubernetes에서는 기본적으로 모든 Pod 간 네트워크 트래픽이 허용되어 모든 Pod가 서로 자유롭게 통신할 수 있다. Calico는 네트워크 계층의 보안을 강화하고, 대규모 클라우드 네이티브 애플리케이션을 보호하기 위한 고급 네트워크 정책을 제공한다. 구성 요소 Calico CNI (Container Network Interface) Calico CNI는 여러 데이터플레인을 제어하는 컨트롤 플레인이다. L3/L4 계층의 네트워크 솔루션으로, 컨테이너, Kubernetes 클러스터, 가상 머신, 호스트 기반 워크로드 간의 안전

!image 각 컨테이너간의 네트워크를 구현한다. 그것은 모두 네트워크 네임스페이스를 통해 구현되고, 서로 비슷한 절차를 거쳐 브릿지를 생성한다. 약간의 차이는 있을 수 있지만 전반적인 흐름은 아주 유사하다. 그렇다면 그 작업을 표준화한 인터페이스를 만든다면 어떨까? 이를 위해 정의된 것이 바로 CNI(Container Network Interface)이다.

Container Orchestration

레드햇(Red Hat)의 정의에 따르면, IT 업계에서 오케스트레이션(Orchestration)이란 용어는 "컴퓨터 자원과 어플리케이션, 서비스에 대한 자동화된 설정, 관리 및 제어 체계"를 의미한다. 비슷한 느낌으로 컨테이너 오케스트레이션은, `"컨테이너화 된 애플리케이션에 대한 자동화된 설정, 관리 및 제어 체계"`로 받아들일 수 있다. 컨테이너 오케스트레이션이 필요한 이유 단일 호스트로 구성된 환경은 확장성(Scalability)과 가용성(Availabilty), 그리고 장애 허용성(Fault Tolerance) 측면에서 많은 한계점을 가지기 때문에, 애플리케이션을 여러개의 호스트로 나누어 구축해야하는 경우가 많다. 마이크로서비스 아키텍처(MSA; Microservice Archite

ContainerRuntime

컨테이너를 쉽게 다운로드받거나 공유하고 구동할 수 있게 도와주는 툴 !image과 컨테이너 이미지의 전송 및 관리, 이미지 압축 풀기 등을 실행하는 고수준 컨테이너 런타임으로 나뉜다. 컨테이너를 실행하려면 저수준 및 고수준 컨테이너 런타임이 각각의 역할을 해야한다. 즉, 컨테이너를 실행

Docker Image Layer

Lets take a contrived example Dockerfile: FROM busybox RUN mkdir /data imagine this is downloading source code RUN dd if=/dev/zero bs=1024 count=1024 of=/data/one RUN chmod -R 0777 /data imagine this is compiling the app RUN dd if=/dev/zero bs=1024 count=1024 of=/data/two RUN chmod -R 0777 /data and now this cleans up that downloaded source code RUN rm /data/one CMD ls -alh /data

dockersock 권한에러

docker 설치 후 /var/run/docker.sock의 permission denied 발생하는 경우 docker 설치 후 usermod로 사용자를 docker 그룹에 추가해도 permission denied가 발생했다. docker ps -a Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.40/containers/json?all=1: dial unix /var/run/docker.sock: connect: permission denied 해결 /var/run/do

Docker Swarm은 도커에서 자체적으로 제작한 컨테이너 오케스트레이션 도구이다. Docker Swarm을 사용한다면 여러 컨테이너의 배포를 관리하고, 네트워크 및 컨테이너 상태를 제어 및 모니터링 할 수 있다. 쿠버네티스와의 차이? 컨테이너 오케스트레이션을 위한 툴로는 여러가지가 있는데 그중 가장 널리 쓰이는 것은 쿠버네티스로, 사실상 표준 기술로 자리잡았다 볼 수 있을 정도로 널리 쓰이고 있다. 하지만 도커 스웜(Docker Swarm)은 Mirantis가 Docker의 엔터프라이즈 플랫폼 사업을 인수한 이래로 유지보수 단계에 접어들어 더 이상의 발전과 기능 추가를 기대할 수 없게 되었다. 그렇다면 도커 스웜보다는 쿠버네티스를 배우는게 좋지 않을까? 굳이 도커 스웜을 사용해야하는 이유가

exec user process caused exec format error

docker image build시 이런 에러가 날 때가 있다. bash exec user process caused “exec format error” m1으로 빌드한 이미지를 서버가 arm 운영체제인 상황에서 돌리려고 할 떄 나는 에러이다. 이 경우 이미지 빌드시 플랫폼을 지정해줌으로써 해결할 수 있다. bash docker buildx build --platform=linux/amd64 ... [Buildx]( Docker는 multi-architecture 빌드 등, 다양한 빌드 옵션을 지원하는 CLI 플러그인인 Buildx를 제공한다. Docker Desktop을 사용하는 Windows나 MacOS 사

Overlay Network

!image 경로로 bridge 네트워크와 연결된다 * bridge를 통해 Single-host networking 효과를 낼 수 있다 * 외부에서 접근시에는 port-mapping이 필요하다 bash $ docker container Usage: docker network COMMAND Manage Docker networks Options: --help

Private registry 구축

🐳 Private registry 구축 내부 Private Cloud 환경에 적용가능한 Docker Private Registry를 구현해보자. 구현하는 이유와 목적은 다음과 같다. Docker Hub등의 Public Registry의 경우 하나의 이미지만 private 등록이 가능하고 organization의 경우 비용을 지불해야 하지만, Private Registry는 제한이 없다. 개인 공간에서 보다 많은 권한을 부여하여 사용할 수 있다. Docker Private registry는 내부망에 Registry를 쉽게 구축해서 프로젝트 단위의 이미지를 관리하기 위한 좋은 방법이다. 1. Docker registry Images 가져오기 bash docker pull registry:

Docker를 오랜 시간 사용하게 되면 여러가지 오브젝트들이 시스템에 쌓이게 된다. 컨테이너나 이미지는 많으면 수십 수백개까지도 늘어난다. Docker 컨테이너, 이미지, 볼륨은 사용중이 아니더라도 디스크를 차지하고 있다. 오브젝트들을 일일히 삭제하거나 통째로 날려버릴 수도 있지만, 사용하지 않는 오브젝트들을 파악해 빠르게 시스템 자원을 확보하는 방법도 있다. prune 서브 커맨드가 바로 이런 역할을 한다. Prune 커맨드를 사용하면 사용하지 않는 컨테이너, 볼륨, 이미지를 일괄적으로 삭제할 수 있다. container docker container prune `--filter` 옵션으로 특정 오브젝트만 삭제할 수도 있다. 중지된 지 1시간 이상 지난 컨테이너만 삭

도커는 LXC(리눅스 컨테이너스)라는 커널 컨테이너 기술을 이용하여 만든 컨테이너 기술 중 하나로, 컨테이너 기반의 오픈소스 가상화 플랫폼이다. 컨테이너를 모듈식 가상머신처럼 유연하게 사용하여 애플리케이션을 안정적으로 배포 및 구축할 수 있도록 한다. 또, 이미지 기반 배포 모델을 제공하고 여러 환경 전반에서 애플리케이션 또는 서비스를 모든 종속 항목과 손쉽게 공유할 수 있다. 운영체제를 가상화하지 않는 컨테이너 기술이기 때문에 가상머신에 비해 가볍고, 한 대의 서버에 여러 애플리케이션을 실행하기 좋다. 단일한 물리적 컴퓨터 위에서 여러 애플리케이션을 돌릴 수 있기 때문에 물리적 하드웨어의 컴퓨팅 용량을 효율적으로 사용할 수 있다. 가상머신(VM)들과 달리, 기존 리눅스 자원(디스크, 네트워크 등)을 그대

가상화와 컨테이너

가상화 가상화는 단일 컴퓨터의 프로세서, 메모리, 스토리지 등과 같은 하드웨어 요소를 가상 머신(VM, Virtual Machine)이라고 하는 다수의 가상 컴퓨터로 분할할 수 있도록 해주는 추상화 계층을 구축하는 기술을 말한다. 실제로는 컴퓨터의 일부에서만 실행됨에도 불구하고, 각각의 VM은 자체적으로 운영체제(Guest OS)를 실행하며 마치 여러개의 컴퓨터인 것 처럼 독립적으로 작동된다. ✔️가상화의 장점 1. 리소스 효율성 가상화 이전에는 애플리케이션마다 별도의 서버를 구성해야했다. 그렇기 때문에 한 애플리케이션이 유휴상태에 있을때는 서버가 활용되지 못한 채 방치된다. 하지만 서버 가상화를 사용하면 단일한 물리적 컴퓨터 위에서 여러 애플리케이션을 돌릴 수 있기 때문에

도커 네트워크

Docker 컨테이너(container)는 격리된 환경에서 돌아가기 때문에 기본적으로 다른 컨테이너와의 통신이 불가능하다. 하지만 여러 개의 컨테이너를 하나의 Docker 네트워크(network)에 연결시키면 서로 통신이 가능해잔다. 다시말해, Docker 네트워크는 컨테이너 간 네트워킹이 가능하도록 도와주는 역할을 한다. 네트워크 종류 Docker는 목적에 따라 다양한 종류의 네트워크 드라이버를 지원한다. 그 종류에 대해 알아보자. none none 네트워크에서 도커 컨테이너는 서로 독립되어서, 정보를 전혀 주고받을 수 없다. 호스트 외부로 접근하는 경우에도 네트워크가 연결되지 않는다. host host 네트워크에서는 host와 컨테이너가 네트워크의 구분 없이 서로 면결

도커 네트워크 명령어

Docker 컨테이너(container)는 격리된 환경에서 돌아가기 때문에 기본적으로 다른 컨테이너와의 통신이 불가능하다. 하지만 여러 개의 컨테이너를 하나의 Docker 네트워크(network)에 연결시키면 서로 통신이 가능해진다. 컨테이너 간 네트워킹이 가능하도록 도와주는 Docker 네트워크에 대해 알아보도록 하자. 네트워크 조회 `docker network ls` 명령어를 사용하면 현재 생성되어 있는 Docker 네트워크 목록을 조회할 수 있다. bash $ docker network ls NETWORK ID NAME DRIVER SCOPE 143496b94e57 bridge bridge

도커 명령어

유용한 도커 명령어를 모아놓은 파일입니다 도커 빌드(dos) js docker build --build-arg DEPENDENCY=build/dependency -t ${유저명}/${레포명} --platform linux/amd64 . docker push ${유저명}/${레포명} 도커 설치, 실행(linux) js sudo yum install docker sudo systemctl start docker 도커 허브에서 이미지 pull 및 실행(linux) js sudo docker pull ${유저명}/${레포명} sudo nohup docker run -p 8080:8080 ${유저명}/${레포명} & 환경변수 파일로 등록 js sudo

도커 스토리지

여러 작업 중 컨테이너 내부에서 생성한 정보, 파일은 컨테이너가 종료된 후에 모두 사라진다. 이러한 데이터를 저장하려면 별도의 저장공간이 필요한데, 컨테이너가 동작 중인 상태에서는 접근이 제한되기 때문에 직접 옮기기는 쉽지 않다. 도커는 스토리지에 파일을 저장하여 컨테이너가 종료되더라도 파일을 유지할 수 있도록 한다. 스토리지는 원본 이미지를 수정 하는 대신 변경된 정보를 따로 저장하고, 원본 데이터와 변경된 정보를 조합해서 복원하는 식으로 데이터를 읽는다. 이렇게 하여 원본 이미지를 수정 할 필요 없이 각 컨테이너마다 다른 정보를 저장 할 수 있다. 스토리지 종류 도커 스토리지의 종류는 3가지가 있다. Volume, bind mount, tmpfs mount이다. 아래 그림은

도커 아키텍처

도커는 client-server architecture를 사용한다. 도커 Client와 Daemon은 UNIX Socket 또는 Network Interface를 기반으로하는 REST API를 사용하여 커뮤니케이션한다. Client에서는 Docker Daemon에 명령어를 보내서, 컨테이너를 빌드, 실행 및 배포하도록 한다. 도커 Client와 Daemon은 같은 시스템 안에서 실행될 수도 있고, remote Docker Daemon에 Client를 연결하여 사용할 수도 있다. 아래 사진을 보며 도커 아키텍처 구조에 대해 더 상세히 알아보자. ![image](

도커 안에서 도커 사용하기

도커를 사용하다보면 모종의 목적으로 도커 컨테이너 안에서 도커를 사용할 일이 생길 수 있다. 이것을 Docker in Docker (DinD)라고 부르는데, 이를 위한 방법은 크게 2가지로 나뉜다. 1. 호스트의 도커 데몬을 사용(마운트)하여 도커 컨테이너 내부에서 호스트의 도커 데몬을 사용하는 방법 2. 도커 컨테이너 내부에서 '실제' 도커를 사용하는 방법 1. 도커 컨테이너 내부에서 호스트의 도커 데몬을 사용하는 방법 이 방법은 도커 컨테이너 내부에서 도커를 사용할 때, 도커 컨테이너 내부의 도커가 아닌, 호스트의 도커 데몬을 사용해서 도커를 사용하는 방법이다. 도커 데몬에게 명령을 내릴 수 있는 인터페이스인 'docker.sock' 파일을 마운트해서 실행하면 된다. 이렇게 설정해주면 도커 컨테

DR(재해 복구)은 비즈니스 연속성 계획의 핵심 요소이다. 재해에 대비하고 복구하는 과정인 DR을 위해 어떻게 아키텍처를 설계할 수 있을까? 재해 이벤트는 워크로드를 중단시킬 수 있기 때문에, DR의 목표는 워크로드를 다시 가동하거나 다운타임을 완전히 방지하는 것이어야 한다. 이를 위해 다음과 같은 목표 지표를 사용한다: Recovery Time Objective (RTO): 서비스 중단부터 서비스 복원까지 허용 가능한 최대 지연 시간이다. 허용 가능한 서비스 다운타임 길이를 결정한다. Recovery Point Objective (RPO): 마지막 데이터 복구 시점 이후 허용 가능한 최대 시간이다. 허용 가능한 데이터 손실량을 결정한다. ![image](

Fail over와 서버 이중화

Fail over fail over는 장애 대비 기능을 의미한다. 컴퓨터 서버, 시스템, 네트워크 등에서 이상이 생겼을 때 미리 준비했던 다른 시스템으로 자동으로 전환해서 무정지 시스템을 운영하여 fail over할 수 있다. failback : 페일오버에 따라 전환된 운용환경을 장애 발생 전 상태로 되돌리는 처리 High Availability(서비스를 정상적으로 사용 가능한 정도를 의미)을 요구할 때 구성한다. 웹 서버, 네트워크 장비, DB 등 다양한 영역에 대비한다. 하드웨어적인 장애 뿐만 아니라 소프트웨어를 포함한 서비스가 운영되지 않은 모든 장애를 포함한다. 서버 이중화 Active-Active 주로 부하 분산 등의 목적, 서비스 단위를 나누어서 분산 다중화 장비 두 대가 모두 활성화

Ansible 구성 요소 제어 노드 control node Ansible을 실행하는 node Ansible 제공 프로그램을 이용하여 매니지드 노드 관리 Ansible이 설치된 computer가 제어 노드가 된다 제어 노드와 매니지드 노드 사이는 SSH를 통해 통신한다. 매니지드 노드 managed node Ansible로 관리하는 서버를 매니지드 노드 또는 호스트(host), 타겟(target) 이라 한다. 매니지드 노드에는 Ansible이 설치되지 않는다. 인벤토리 Inventory 매니지드 노드 목록 인벤토리 파일은 호스트 파일 이라고도 한다. 인벤토리 파일은 각 매니지드 노드에 대한 IP Address, 호스트 정보, 변수 와 같은 정보를 저장 모듈 modu

Cobbler는 네트워크 설치 환경을 빠르게 설정할 수 있게 해주는 Linux 설치 서버이다. 새 시스템을 배포할 때(경우에 따라 기존 시스템을 변경할 때도) 여러 명령어와 애플리케이션 사이를 오가지 않아도 되도록, 관련된 많은 Linux 작업을 결합하고 자동화해준다. Cobbler는 프로비저닝, DNS 및 DHCP 관리, 패키지 업데이트, 전원 관리, 구성 관리 오케스트레이션을 도울 수 있다. 구성 관리 시스템이 업데이트를 단순화하기 위해 템플릿에 의존하는 것처럼, Cobbler도 마찬가지이다. 템플릿은 DNS, DHCP 같은 서비스 관리와 다양한 배포판에 제공되는 응답 파일(kickstart, preseed 등)에 광범위하게 사용되며, 코드 재사용을 극대화하기 위해 모두 템플릿화되어 있다. 템플릿 외

Configuration Drift

Configuration Drift는 수동적이고 임시방편적인 변경, 업데이트, 그리고 일반적인 엔트로피로 인해 인프라의 서버들이 시간이 지남에 따라 서로 점점 더 달라지는 현상이다. 자동화된 서버 프로비저닝 프로세스는 머신이 생성될 때 일관성을 보장하는 데 도움이 되지만, 특정 머신의 생명주기 동안 기준선(baseline)과 다른 머신들로부터 표류(drift)하게 된다. Configuration drift에 대응하는 두 가지 주요 방법이 있다. 하나는 Puppet이나 Chef와 같은 자동화된 구성 도구를 사용하여 머신을 일관되게 유지하기 위해 자주 반복적으로 실행하는 것이다. 다른 하나는 머신 인스턴스를 자주 재구축하여 기준선에서 표류할 시간을 주지 않는 것이다. Configuration drift가

예전에 일반적으로 서버를 운영할때는 주로 서버를 설치한 후 OS를 설치한 후에, 필요한 소프트웨어와 애플리케이션을 설치하여 운영하였다. 여기에 문제가 생긴 경우 패치를 하거나 정기적인 보안 패치 튜닝들을 해당 서버에 지속적으로 적용하고, 애플리케이션은 CI/CD 등의 툴을 이용하여 배포하는 구조를 가지고 있었다. 이렇게 한번 설치한 서버에 계속해서 설정을 변경하고 패치를 적용하는 등의 업데이트를 지속적으로 적용하여 운영하는 서버를 Snowflakes Server라고 하는데, 이렇게 설정된 서버는 다시 똑같이 설정하기가 매우 어렵다. 모든 설정과정이 문서화가 잘되어 있으면 모르겠지만 대부분 문서화가 꼼꼼한 경우가 굉장히 드물고, 담당자가 바뀌거나 관리 조직이 바뀌는 경우에는 그 이력이 제대로 유지되는

aws 서버 네트워크 구축

1. 네트워크 구성 hcl resource "aws_vpc" "scenario_1_vpc" { cidr_block = "172.16.0.0/26" tags = { Name = "scenario-1-vpc" } } VPC는 AWS에서 다루는 네트워크의 기본단위이다. 사용자들이 앞으로 만들 서버와 인터넷을 통해 통신하기 위해선 네트워크 구축이 필요한데 가장 먼저 VPC를 만들어주어야 한다. cidr_block을 통해 어떤 ip 대역을 사용할지 결정한다. 보통 `10.0.0.0/8`, `172.16.0.0/16`, `192.168.0.0/24`의 private ip 대역을 사용하지만 공인 ip 대역 역시 사용이 가능하다. 다만 공인 ip 대역 사용시 인터넷을 통한 통신이 불가

Terraform is an open source “Infrastructure as Code” tool, created by HashiCorp. A declarative coding tool, Terraform enables developers to use a high-level configuration language called HCL (HashiCorp Configuration Language) to describe the desired “end-state” cloud or on-premises infrastructure for running an application. It then generates a plan for reaching that end-state and executes the plan

Terraform import와 Terraforming

이미 사용하고 있는 인프라를 Terraform으로 가져오려면 import 명령어를 사용해야한다. The current implementation of Terraform import can only import resources into the state. It does not generate configuration. A future version of Terraform will also generate configuration. import 명령어를 사용하면 상태 파일에 기존 리소스의 상태가 적용된다. import는 아래와 같이 사용할 수 있다. bash $ terraform import {유형}.{이름} {식별자} $ terraform import aws_instance.web i-123456

Terraform taint

terraform taint는 특정 리소스를 "tainted" 상태로 표시하여, 다음 terraform apply 때 해당 리소스를 강제로 다시 만들게 한다. 특정 리소스를 교체해서 테스트하거나 디버깅해보고 싶을때 taint를 이용할 수 있다. 예제 igw에 장애가 있다고 가정해보자. 우선 `tf state list`를 통해 state 목록을 출력한다. bash $ tf state list module.route_table__private.aws_resourcegroups_group.this[0] module.route_table__private.aws_route_table.this module.route_table__private.aws_route_table_association.subnets

Terraform with AWS

AWS Provider로 간단한 인프라를 구성해보자. 우선 AWS IAM에 가서 Terraform이 사용할 계정을 만들고, 사용할 서비스 VPC, EC2에 대한 권한을 부여한다. 생성된 계정에 할당된 access key와 secret key로 다음과 같은 aws.tf 파일을 생성한다. hcl provider "aws" { access_key = "ACCESS-KEY" secret_key = "SECRET-KEY" region = "ap-northeast-2" } 이제 AWS 리소스를 정의할 때 이 파일을 이용하게 된다. Terraform을 사용하면 API Gateway, App Autoscaleing, CloudFomation, CloudFront, CloudWatch

Terraform 키워드

resource는 테라폼에서 가장 중요한 요소이다. resource 블록은 하나 이상의 인프라스트럭처의 오브젝트를 기술한다. 아래는 providers로 AWS를 사용하고 있을 때 인스턴스를 사용하는 예제이다. hcl resource "aws_instance" "web" { ami = "ami-a1b2c3d4" instance_type = "t2.micro" } 위에 첫 번째 라인을 살펴보면 resource 옆에 첫 번째 자리는 리소스 타입으로 “aws_instance”를 써주고 두 번째 자리에는 “web”을 적어줬다. 리소스 타입은 사전에 정의된 AWS 리소스 이름이다. 여기서 “aws_instance”는 인스턴스를 나타내고 있다. aws라는 프로바이더 정보를 pre

Terratest has a pretty simple premise. It is ans open-source testing framework created by Terragrunt the includes helper functions for testing terraform code by providing a simple, reusable, and easy-to-use interface for creating and running automated tests on cloud resources. It's able to apply terraform code, provision the resources, run the test cases, and then destroy everything. Terratest is

Understanding Ansible, Terraform, Puppet, Chef, and Salt

Choosing the automation solution that works best for your organization is no easy task. There’s not a single "right" approach—you can automate your enterprise in multiple ways. Indeed, many IT organizations today use more than one automation tool, and a major consideration is how well they work together to achieve business goals. Other factors to keep in mind when evaluating automation tools inc

Add IAM to RBAC

Add new IAM user or role to the Kubernetes RBAC, using kubectl or eksctl Before you choose the kubectl or eksctl tool to edit the aws-auth ConfigMap, make sure that you complete step 1. Then, follow steps 2-4 to edit with kubectl. To edit with eksctl, proceed to step 5. 1. After you identify the cluster creator or admin, configure AWS CLI to use the cluster creator IAM. See Configuration basics

The AWS-provided VPC CNI is the default networking add-on that runs on Kubernetes worker nodes for EKS clusters. VPC CNI add-on is installed by default when you provision EKS clusters. The VPC CNI provides configuration options for pre-allocation of ENIs and IP addresses for fast Pod startup times.\ VPC CNI components Amazon VPC CNI has two components: CNI Binary: which will setup Pod net

AWS Load Balancer Controller

AWS Load Balancer Controller is a controller to help manage Elastic Load Balancers for a Kubernetes cluster. It satisfies Kubernetes Ingress resources by provisioning Application Load Balancers. It satisfies Kubernetes Service resources by provisioning Network Load Balancers. This project was formerly known as "AWS ALB Ingress Controller", we rebranded it to be "AWS Load Balancer Controller".

EKS 환경에서 EBS에 데이터를 영속적으로 저장하고 싶다면, AWS에서 제공하는 EBS CSI driver 애드온을 사용할 수 있다. 사전에 IAM OIDC 프로바이더를 활성화하고 EBS CSI driver용 IAM 역할을 생성해야 한다. 가장 쉬운 방법은 eksctl을 사용하는 것이다(일반 AWS CLI나 AWS 콘솔을 사용하는 방법은 공식 문서에 설명되어 있다). 1. IAM OIDC 프로바이더 활성화 클러스터에 IAM OIDC 프로바이더가 있어야 한다: bash eksctl utils associate-iam-oidc-provider --region=eu-central-1 --cluster=YourClusterNameHere --approve 2. Amazon EBS

Kubernetes `ingress`를 생성하면 애플리케이션 트래픽을 로드 밸런싱하는 AWS Application Load Balancer(ALB)가 프로비저닝된다. ALB는 노드에 배포된 Pod나 AWS Fargate Pod와 함께 사용할 수 있다. ALB를 퍼블릭 또는 프라이빗 서브넷에 배포할 수 있다. 애플리케이션 트래픽을 로드 밸런싱하기 전에 다음 요구사항을 충족해야 한다. 사전 조건 기존 클러스터가 있어야 한다. 클러스터에 AWS Load Balancer Controller가 배포되어 있어야 한다. 서로 다른 가용 영역에 최소 두 개의 서브넷이 필요하다. AWS Load Balancer Controller는 각 가용 영역에서 하나의 서브넷을 선택한다. 한 가용 영역에 태그가 지정된 서브

EKS Control Plane

EKS is a managed Kubernetes service that mekes it easy for you to run Kubernetes on AWS without needing to install, operate, and main your own Kubernetes control plane or worker nodes. It runs ipstream Kubernetes and is certified Kubernetes conformant. EKS automatically manages the availability and scalability of the Kubernetes control plane nodes, and it automatically replaces unhealthy control

EKS 기본 환경 Setting 방법을 알아보자. 쿠버네티스는 kubectl에 대한 인증정보를 kubeconfig라는 yaml파일에 저장한다. EKS 클러스터는 어떻게 접근을 하는지, 어떻게 인증을 받아오는지 알아보자. Kubeconfig EKS 클러스터에 접근 가능한 kubeconfig파일을 생성하는 것은 간단하다. aws command 한 줄이면 인증 정보를 kubeconfig 파일에 저장할 수 있다. bash aws eks --region update-kubeconfig --name kubeconfig 파일 내용을 살펴보자. yml apiVersion: v1 clusters: cluster: server: certificate-authority-data

EKS Network BestPractice

It is critical to understand Kubernetes networking to operate you cluster and applications efficiently. Pod networkin, also called the cluster networking, is the center of Kubernetes networkin. Kubernetes supports [Container Network Interface]( plugins for cluster networking. Amazon EKS officially supports VPC CNI plugin to implement Kubernetes Pod

EKS 인증과정

kubectl에서 EKS Cluster의 K8s API Server에 접근하거나, Worker Node에서 동작하는 kubelet에서 EKS Cluster의 K8s API Server 접근시에는 AWS IAM Authenticator가 이용된다. 왼쪽은 kubelet의 kubeconfig이고, 오른쪽은 kubectl의 kubeconfig이다. 두 kubeconfig 모두 user 부분을 확인해보면 `aws eks get-token` 명령어를 수행하는 것을 확인할 수 있다. `aws eks get-token` 명령어는 해당 명령어를 수행하는 Identity가 누구인지 알려주는 AWS STS의 GetCallerIdentity API의 Presigned URL을 생성하고, 생성한 URL을 Enc

IP addresse prefix

각 Amazon EC2 인스턴스는 지원할 수 있는 elastic network interface의 최대 개수와 각 네트워크 인터페이스에 할당할 수 있는 IP 주소의 최대 개수가 정해져 있다. 각 노드는 네트워크 인터페이스당 하나의 IP 주소가 필요하다. 그 외 사용 가능한 모든 IP 주소는 Pod에 할당될 수 있다. 각 Pod는 고유한 IP 주소가 필요하다. 결과적으로, 노드에 사용 가능한 컴퓨팅 및 메모리 리소스가 있더라도 Pod에 할당할 IP 주소가 부족하여 추가 Pod를 수용할 수 없는 상황이 발생할 수 있다. 노드에 개별 보조 IP 주소를 할당하는 대신 IP prefix를 할당하면 노드가 Pod에 할당할 수 있는 IP 주소 수를 크게 늘릴 수 있다. 각 prefix에는 여러 개의 IP 주소가

AWS Load Balancer Controller는 Kubernetes `LoadBalancer` 타입 서비스에 적절한 어노테이션을 통해, Amazon EC2 인스턴스와 AWS Fargate에서 실행되는 Pod에 대한 IP 대상 모드의 Network Load Balancer(NLB)를 지원한다. 이 모드에서는 AWS NLB가 트래픽을 서비스 뒤의 Kubernetes Pod로 직접 타겟팅하므로, 워커 노드를 통한 추가적인 네트워크 홉이 필요 없다. 설정 NLB IP 모드는 서비스 객체에 추가된 어노테이션을 기반으로 결정된다. IP 모드의 NLB를 사용하려면 서비스에 다음 어노테이션을 적용한다: yaml metadata: name: my-service annotations:

A Kubernetes node is a physical or virtual machine participating in a Kubernetes cluster, which can e used to run pods. When a node shuts down or crashed, it enters the NotReasy state, meaning it cannot be used to run pods. All stateful pods running on the node then becom unavailable. Common reasons for a Kubernetes `node not ready` error include lack of resources on the node, a problem w

K8s Architecture

쿠버네티스는 중앙(Master)에 API 서버와 상태 저장소를 두고 각 서버(Node)의 에이전트(kubelet)와 통신하는구조로 동작한다. 하지만 이 개념을 여러 모듈로 쪼개어 구현하고 다양한 오픈소스를 사용하기 떄문에 설치가 까다롭고 구성이 복잡해보일 수 있다. 마스터-노드 구조 쿠버네티스는 전체 클러스터를 관리하는 마스터와 컨테이너가 배포되는 노드로 구성되어있다. 모든 명령은 마스터의 API 서버를 호출하고 노드는 마스터와 통신하면서 필요한 작업을 수행한다. 특정 노드의 컨테이너에 명령하거나 로그를 조회할 때도 노드에 직접 명령하는게 아니라 마스터에 명령을 내리고 마스터가 노드에 접속하여 대신 결과를 응답한다. Master 마스터 서버는 다양한 모듈이 확장성을 고려하여 기능별로

쿠버네티스(Kubernetes)는 컨테이너화 된 애플리케이션의 대규모 배포, 스케일링 및 관리를 간편하게 만들어주는 오픈 소스 기반 컨테이너 오케스트레이션 도구이다. 프로덕션 환경에서는 애플리케이션을 실행하는 여러 컨테이너를 관리하고 다운타임이 없는지 확인해야하는데, Kubernetes는 다중 컨테이너 처리를 자동으로 처리하고, 분산 시스템을 탄력적으로 실행할 수 있는 프레임워크를 제공한다. K8s를 사용하면 애플리케이션의 확장 및 장애 조치를 처리하고 배포 패턴 등을 쉽게 처리할 수 있다. 쿠버네티스의 특징 5가지 1. 선언적 접근 방식 쿠버네티스에서는 동작을 지시하는 개념보다는 상태를 선언하는 개념을 주로 사용한다. 쿠버네티스는 원하는 상태(Desired state)와 현재의 상태(Cu

Kubernetes Overview Diagrams

![image]( ![image]( ![image]( ![image](

Debugging DNS Resolution

You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. Create a simple Pod to use as a test environment yaml apiVersion: v1 kind: Pod metadata: name: dnsutils namespace: default spec: containers:

두개의 포드와 서비스가 있다고 해보자. 각 포드의 이름은 test와 web이고, 가상 IP를 하나씩 할당받았다. /-----\ /-------- /-----\ | pod | 《 service | pod | \-----/ \-------- \-----/ 10.244.1.5 10.107.37.188 10.244.1.5 test web-service web 서비스가 생성되면, k8s DNS sevice(CoreDNS)는 해당 서비스를 위한 레코드를 저장한다. 즉, ip를 직접 명시하지 않고 사용할 수

ExternalDNS는 kubernetes dns(kube-dns)와 상반되는 개념으로 내부 도메인서버가 아닌 Public한 도메인서버(AWS Route53, GCP DNS 등)를 사용하여 쿠버네티스의 리소스를 쿼리할 수 있게 해주는 오픈소스 솔루션이다. ExternalDNS를 사용하면 public도메인 서버가 무엇이든 상관없이 쿠버네티스 리소스를 통해서 DNS레코드를 동적으로 관리 할 수 있다. ExternalDNS 설치 쿠버네티스 서비스 계정에 IAM 역할을 사용하려면 OIDC 공급자가 필요하다. IAM OIDC 자격 증명 공급자를 생성한다. bash eksctl utils associate-iam-oidc-provider --cluster {cluster name} --approve `

생성된 서비스의 IP는 어떻게 알 수 있을까? 서비스가 생성된 후 kubectl get svc를 이용하면 생성된 서비스와 IP를 받아올 수 있지만, 이는 서비스가 생성된 후이고, 계속해서 변경되는 임시 IP이다. DNS를 이용하는 방법 가장 쉬운 방법으로는 DNS 이름을 사용하는 방법이 있다. 서비스는 생성되면 `[서비스 명].[네임스페이스명].svc.cluster.local` 이라는 DNS 명으로 쿠버네티스 내부 DNS에 등록이 된다. 쿠버네티스 클러스터 내부에서는 이 DNS 명으로 서비스에 접근이 가능한데, 이때 DNS에서 리턴해주는 IP는 외부 IP (External IP)가 아니라 Cluster IP (내부 IP)이다. 간단한 테스트를 해보자. hello-node-svc 가 생성이 되었는데,

eBPF는 커널에서 샌드박스된 특별한 프로그램을 실행할 수 있게 해주는 프로그래밍 시스템이다. Netfilter나 iptables처럼 커널과 유저 공간을 오가지 않고 커널 내에서 직접 동작한다. eBPF 이전에는 BPF(Berkeley Packet Filter)가 있었다. BPF는 커널에서 네트워크 트래픽을 분석하는 데 사용되는 기술이다. BPF는 패킷 필터링을 지원하는데, 유저 공간 프로세스가 어떤 패킷을 검사할지 지정하는 필터를 제공할 수 있다. BPF의 대표적인 사용 사례가 `tcpdump`다. tcpdump는 필터를 BPF 프로그램으로 컴파일해서 BPF에 전달한다. BPF의 기법은 이후 다른 프로세스와 커널 작업으로 확장되었다. tcpdump 예제 bash $ sudo tcp

IP Virtual Server (IPVS)는 Linux의 connection(L4) 레벨 로드 밸런서이다. iptables는 개별 DNAT 규칙의 가중치로 형성된 무작위성을 통해 연결을 무작위로 라우팅함으로써 간단한 L4 로드 밸런싱을 수행할 수 있다. 하지만 IPVS는 iptables와 달리 여러 로드 밸런싱 모드를 지원한다. 이를 통해 IPVS는 구성과 트래픽 패턴에 따라 iptables보다 더 효과적으로 부하를 분산할 수 있다. 로드 밸런싱 모드 IPVS는 다음과 같은 로드 밸런싱 모드를 제공한다. |이름|코드|설명| |-|-|-| |Round-robin|rr|순환 방식으로 다음 호스트로 연속적인 연결을 전송한다. iptables의 무작위 라우팅과 비교하여 특정 호스트로 전송되는

Network Troubleshooting

각 상황에 맞는 네트워크 트러블슈팅 도구를 정리하면 다음과 같다: |상황|도구| |-|-| |연결 확인|`traceroute`, `ping`, `telnet`, `netcat`| |포트 스캔|`nmap`| |DNS 레코드 확인|`dig`, 연결 확인 도구들| |HTTP/1 확인|`cURL`, `telnet`, `netcat`| |HTTPS 확인|`OpenSSL`, `cURL`| |리스닝 프로그램 확인|`netstat`| 보안 본격적으로 도구를 다루기 전에, 보안에 대해 먼저 인지해야 한다. 공격자는 여기 소개된 모든 도구를 이용해 시스템을 탐색하고 침투할 수 있다. 그래서 최선의 방법은 각 머신에 최소한의 네트워킹 도구만 설치하는 것이다. 물론 공격자가 직접 도구를 다운로드하거나 패키지 매니저를

Kubernetes's default befavior is to allow traffic between any two pods in the cluster network. This behavior is a deliberate design choice for ease of adoption and flexibility of configuration, but it is highly undesirable in practice. Allowing any system to make (or receive) arbitrary connections creates risk. An attacker can probe systems and can porentially exploit captured credentials to find

Node and Pod Network Layout

The cluster must have a group of IP addresses that is controls to assign an IP address to a pod, for example, `10.1.0.0./16`. Nodes and pods must have L3 conectivity in this IP address space. In L3, ths Internet layer, connectivity means packets with an IP address can route to a host with that IP address. It is important to note that the ability to deliver packets is more fundamental than creatin

A dry run (or practice run) is a software testing process used to make sure that a system works correctly and will not result in severe failure. Istio has a experimental annotation `istio.io/dry-run` to dry-run the policy without actually enforcing it. The dry-run annotation allows you to better understand the effect of an authorization policy before applying it to the production traffic. This h

gateway log debug 하는 법

Debugging Istio Envoy filters can be challenging but there are several techniques and tools that can help you troubleshoot issues. Here's a step-by-step guide to debug Istio Envoy filters: 1. Enable Debug Logs: By default, Istio's Envoy sidecar logs only contain essential information. To get more detailed logs, you can enable debug logging by changing the log level. To do this, you'll need to mo

Istio Arcitecture

An Istio service mesh is logically split into a data plane and a control plane. The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices. They also collect and report telemetry on all mesh traffic. The control plane manages and configures the proxies to route traffic. The following

Istio authorization

Istio는 `ClusterRbacConfig`를 통해 ServiceRole에 권한 Rule을 정의한 후 ServiceRoleBinding을 통해 특정 대상에 해당 ServiceRole에 지정하여 접근 제어를 수행한다. mesh, namespace, workload 범위에서의 access control을 적용할 수 있다. Istio authorization을 사용했을 때 얻을 수 있는 이점은 아래와 같다. 간단한 API: AuthorizationPolicy CRD를 통해 쉬운 접근 제어가 가능하다. 유연한 설정: CUSTOM, DENY 및 ALLOW 등 Istio 특성에 대한 사용자 지정 조건을 자유롭게 정의할 수 있다. 고성능: Envoy native를 사용하기에 성능이 우수하다. 높은 호환성: gRP

Istio Configuration Profiles

default: enables components according to the default settings of the IstioOperator API. This profile is recommended for production deployments and for primary clusters in a multicluster mesh. You can display the default settings by running the istioctl profile dump command. demo: configuration designed to showcase Istio functionality with modest resource requirements. It is suitable to ru

Istio RBAC를 통해 네임스페이스, 서비스, HTTP 메소드 수준의 권한 제어를 실습 해보자. 준비작업 1. k8s, helm 설치 2. Istio 초기화 (namespace, CRDs) bash $ wget $ tar -vxzf istio-1.8.2-osx.tar.gz $ cd istio-1.8.2 $ kubectl create namespace istio-system $ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kube

bash istioctl proxy-status NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION argocd-application-controller-0.argocd Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-977466b69-2kms7 1.18.2 argocd-applicationset-controlle

Resource Annotations & Labels

The various resource annotations that Istio supports to control its behavior. |Annotation|Name|Resource Types|Description| |-|-|-|-| |`galley.istio.io/analyze-suppres`s|[Any]|A comma separated list of configuration analysis message codes to suppress when Istio analyzers are run. For example, to suppress reporting of IST0103 |(PodMissingP

Since not all services live in the sevice mesh, we need a way for services inside the mesh to communicate with those outdise the mesh. Those could be existing HTTP services or, more likely, infrastructure services like databases or caches. We can still implement sophisticated routing for services that reside outside Istio, but first we have to introduce the concept of a `ServiceEntry`. Istio

Chart Development Tips

Template Functions Helm uses Go templates for templating your resource files. While Go ships several built-in functions, we have added many others. First, we added all of the functions in the Sprig library, except env and expandenv, for security reasons. We also added two special template functions: include and required. The include function allows you to bring in another template, and then pa

Helm이란, kubernetes 패키지 관리를 도와주는 tool이다. Node.js의 npm, Python의 pip와 같은 역할이라고 볼 수 있다. Chart Helm은 차트라고 불리는 Package formet을 사용한다. 차트는 Kubernetes Resouce들의 내용을 나타내는 파일들의 집합이다. 예를 들어 `Wordpress`의 차트는 아래와 같은 구조를 가지고있다. bash wordpress/ Chart.yaml chart에 대한 정보 LICENSE (optional) chart의 license에 대한 정보 README.md (optional) 사람이 읽을 수 있는 README 파일 requirements.yaml

Values is One of the built-in objects. This object provides access to values passed into the chart. Its contents come from multiple sources: The `values.yaml` file in the chart If this is a subchart, the `values.yaml` file of a parent chart A values file if passed into helm install or helm upgrade with the -f flag (`helm install -f myvals.yaml ./mychart`) Individual parameters passed with `--set`

Let’s deploy Cilium for testing with our Golang web server in below example. We will need a Kubernetes cluster for deploying Cilium. One of the easiest ways we have found to deploy clusters for testing locally is KIND, which stands for Kubernetes in Docker. It will allow us to create a cluster with a YAML configuration file and then, using Helm, deploy Cilium to that cluster. KIND configuration

Karpenter의 스케줄링 우선순위 Karpenter는 pod를 스케줄링할 때 아래와 같은 순서로 조건을 체크하여 스케줄할 노드를 선택한다: 1. 기존 노드 활용 시도 (`addToExistingNode`) 이미 존재하는 노드에 추가 가능한지 확인 단, toleration하지 않은 taint가 붙어있으면 불가 (PreferNoSchedule 포함) 2. 생성 중인 노드 활용 (`addToInflightNode`) 현재 생성 중인 노드에 추가 가능한지 확인 3. 새 노드 생성 (`addToNewNodeClaim`) 새로운 노드를 추가해서 스케줄링 가능한지 확인 4. 제약 조건 완화 (Relax) Affinity, Topology 무시하고

Kyverno(Greek for “govern”) is a policy engine designed for Kubernetes. It can validate, mutate, and generate configurations using admission controls and background scans, Kyverno policies are Kubernetes resources and do not require learning new language. Kyverno is designed to work nicely with tools you already use like kubectl, kustomize, and Git. Featchers Kyverno is a policy engine designed

Kyverno is a Kubernetes native policy engine that helps in enforcing custom policies on Kubernetes objects. It is a highly scalable and declarative tool that allows Kubernetes administrators to enforce security, compliance, and operational policies across their clusters. Kyverno policies are written in YAML format and can be defined as cluster-wide resources (using the kind ClusterPolicy) or name

K8s에서 LB를 사용하기 위해선 AWS, GCP, Azure 등 플랫폼에서 제공해주는 서비스를 사용해야하고, 온프레미스 클러스터에서는 추가 모듈 설치가 필요하다. MetalLB는 BareMetal Loadbalancer의 약자로, 베어메탈 환경에서 사용할 수 있는 로드밸런서를 제공하는 오픈소스 프로젝트이다. MetalLB의 동작에는 두가지 방식이 있다. 1. L2 Mode L2 모드는 2계층 통신을 이용한다. 1. 각 노드마다 speaker라는 데몬셋이 생성되고, 호스트 네트워크를 사용한다. 2. 리더 speaker pod를 선출한다. 리더는 ARP(GARP)로 해당 External IP에 대한 소유를 주장한다. arpping을 이용하여 어떤 Speaker pod가 external IP를

kubernetes node에 쉽게 접속할 수 있도록 하는 kubectl 플러그인이다. 워커노드, 인그레스노드에 접근이 가능하고 root 권한으로 실행이 가능하다. krew 설치하기 node-shell는 krew를 통해 설치할 수 있다. bash krew 설치하기 $ brew install krew krew에 kvaps 추가 $ kubectl krew index add kvaps node-shell 설치하기 bash node-shell을 설치한다. $ kubectl krew install kvaps/node-shell export 추가하기 bash vi 편집기 사용하여 ~/.zshrc

Node Termination Handler

Node Termination Handler는 EC2 인스턴스가 [EC2 maintenance events]( [EC2 Spot interruptions]( [ASG Scale-In]( ASG AZ 재조정, an

The [Open Policy Agent Gatekeeper]( project can be laveraged to help enforce policies and strengthen governence in your Kubernetes environment. If your organization has been operating Kubernetes, you probably have been looking for ways to control what end-users can do on the cluster and ways to ensure that clusters are in compliance with company po

CNI Specification

The CNI specification itself is quite simple. According to the specification, there are four operations that a CNI plugin must support: `ADD`: Add a container to the network. `DEL`: Delete a container from the network. `CHECK`: Return an error if there is a problem with the container’s network. `VERSION`: Report version information about the plugin. The full CNI spec is available on [GitHub](htt

Disruption Budget

Let's explore to limit the number of concurrent disruptions that your application experiences, allowing for higher availability while permitting the cluster administrator to manage the clusters nodes. The most common use case when you want to protect an application specified by one of the build-in Kubernetes controllers: Deployment ReplicationController ReplicaSet StatefulSet In this case, make

쿠버네티스의 Services는 뒷단에 있는 Pod의 label 정보를 바탕으로한 selector로 그 대상이 되는 Pod를 매칭한다. 만약 해당 Label을 단 새로운 Pod이 생겼다면, Service는 자동으로 그 Pod과 연결되어 트래픽을 보낸다. 이러한 일이 가능한 것은 service가 트래픽을 보낼 오브젝트를 추적해주는 `EndPoint`가 있기 때문이다. 매칭된 Pod의 IP 주소는 그 service의 endpoint가 되어 연결된다. service는 endpoints를 통해 트래픽을 보내는 주소의 목록을 관리한다. endpoints는 labels와 selectors를 통해 자동으로 업데이트 될 수 있다. 그리고 경우에 따라 수동으로 endpoints를 설정할 수 있다. serv

etcd는 key:value 형태의 데이터를 저장하는 스토리지이다. Kubernetes는 기반 스토리지(backing storage)로 etcd를 사용하고 있고, 모든 데이터를 etcd에 보관한다. 클러스터에 어떤 노드가 몇 개나 있고 어떤 파드가 어떤 노드에서 동작하고 있는지 등의 정보가 etcd에 저장되는 것이다. RSM(Replicated state machine) etcd는 분산 컴퓨팅 환경에서 서버가 몇 개 다운되더라도 정상적으로 동작하는 Replicated state machine(RSM)방식으로 구현되었다. RSM은 위 그림과 같이 command가 들어있는 log 단위로 데이터를 처리한다. 데이터를 write하는 것을 `log append`라고 부르고, 머신은 받은 log를 순서대로

HPA(Horizontal Pod Autoscaler) Horizontal Pod Autoscaler는 metric server를 통해 파드의 리소스를 감시하여 리소스가 부족한 경우 Controller의 replicas를 증가시켜 파드의 수를 늘린다. 위의 그림 처럼 Pod가 수평적으로 증가하는 것을 Scale Out, 수평적으로 감소하는 것을 Scale In 이라고 한다. Pod를 증가시키기 때문에 기존의 트래픽이 분산되어 서비스를 더 안정적으로 유지할 수 있게 된다. Replica의 수와 상관 없이 돌아갈 수 있는 Stateless 서비스에 적합하다. 트래픽이 급증하여 spike가 생기는 경우에 대응할 수 있다. 사용하는 매트릭과, 목표하는 매트릭을 계산하여 desire replica 수를

K8s의 도커런타임 사용중단

!image GKE 및 EKS 등의 관리 Kubernetes 서비스를 사용하는 경우 오퍼레이터에서 지원되는 버전의 런타임을 사용하는 것을 확인하고 쿠버네티스 릴리스에서 도커 지원이 만료되기 전에 변경 해야한다. 자세한 내용은 아래와 같다. Depreca

`kube-proxy`는 Kubernetes의 노드별 데몬이며, Service를 사용 가능한 네트워킹 규칙으로 변환하는 역할을 한다. 정확히는, Service에 따른 Endpoint들을 등록한다. Service는 Pod 집합에 대한 로드 밸런서를 정의한다. Endpoint(및 endpoint slice)는 준비된 Pod IP 목록을 나열한다. Service와 동일한 Pod 셀렉터를 사용하여 Service로부터 자동으로 생성된다. 대부분의 Service 유형은 클러스터 외부에서 라우팅할 수 없는 cluster IP 주소라고 하는 Service용 IP 주소를 가지고 있다. `kube-proxy` is responsible for routing requests to a service’s cluster

Assigning Pods to Nodes

node-scheduling

You can constrain a Pod so that it is restricted to run on particular node(s), or to prefer to run on particular nodes. There are several ways to do this and the recommended approaches all use label selectors to facilitate the selection. Often, you do not need to set any such constraints; the scheduler will automatically do a reasonable placement (for example, spreading your Pods across nodes so

node-scheduling

쿠버네티스 클러스터를 사용하다 보면 특정 노드에 있는 포드들을 모두 다른 곳으로 옮기거나 아니면 특정 노드에는 포드들이 스케쥴링 되지 않도록 제한을 걸어야 할 때가 있다. 이러한 기능들을 제공하는 kubectl 명령어가 cordon, drain, taint 등이다. cordon kubectl cordon은 지정된 노드에 더이상 포드들이 스케쥴링되서 실행되지 않도록 한다. kubectl get nodes로 노드 이름을 확인한 다음에 cordon을 해보자. cordon을 한 다음에 다시 노드를 확인해 보면 노드의 status에 SchedulingDisabled라는 STATUS가 추가된 걸 확인할 수 있다. bash $ kubectl get nodes NAME STATUS

Taints and Tolerations

node-scheduling

Node affinity is a property of Pods that attracts them to a set of nodes (either as a preference or a hard requirement) Taints are the opposite -they allow a node to repel a set of pods. Tolerations are applied to pods. Tolerations allow the scheduler to schedule pods with matching taints. Tolerations allow scheduling but don't guarantee scheduling: the scheduler also evaluates other para

NodePort와 ServicePort와 targetPort

K8s의 포트는 노드와 서비스, 컨테이너별로 나뉘어있다. 이 개념에 대해 확실히 알아보자. 만약에 하나의 서비스에 2개의 노드가 있고, 그 노드에 각각 하나의 포드가 있다고 하면 아래 그림과 같은 모양이 된다. NodePort는 각 노드의 클러스터 레벨에서 노출되는 포트, (그림에서 `30001`) Port는 서비스의 포트, (`80`) targetPort는 포드에서 컨테이너로 가는 앱 컨테이너 포트를 말한다. 아래와 같이 설정할 수 있다. yml ports: protocol: TCP port: 80 targetPort: 8080 nodePort: 30000

You can use Kubernetes annotations to attach arbitrary non-identifying metadata to objects. Clients such as tools and libraries can retrieve this metadata. You can use either labels or annotations to attach metadata to Kubernetes objects. Labels can be used to select objects and to find collections of objects that satisfy certain conditions. In contrast, annotations are not used to identify

Custom resources are extensions of the Kubernetes API. This page discusses when to add a custom resource to your Kubernetes cluster and when to use a standalone service. It describes the two methods for adding custom resources and how to choose between them. Custom resources A resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind; for example, t

Deployment Status

A Deployment enters various states during its lifecycle. It can be progressing while rolling out a new ReplicaSet, it can be complate, or it can fail to progress. Progressing Deployment Kubernetes marks a Deployment as progressing when one of the follwing tasks is performed: The Deployment creates a new ReplicaSet. The Deployment is scaling up its newest ReplicaSet. The Deployment is scaling do

Deployment Strategy

Deployment's `.spec.strategy` specifies the strategy used to replace old Pods by new ones. `.spec.strategy.type` can be "Recreate" or "RollingUpdate". "RollingUpdate" is the default value. Recreate Deployment All existing Pods are killed before new ones are created when `.spec.strategy.type==Recreate`. Note: This will only guarantee Pod termination previous to creation for upgrades. If you u

Deplotment는 Pod와 ReplicaSets를 위한 선언적 업데이트를 제공한다. `Deployment`는 k8s의 핵심 개념중 하나인 `desired state`(목표 상태)를 설명하는 요소이다. Deployment에서 desired state를 정의하면 배포 컨트롤러가 원하는 상태로 복구한다. Deploy를 만들어 실습해보자! 더 자세하고 정확한 설명은 공식 를 참고하자. Creating a Deployment yml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels:

Kubernetes Events는 하나의 Kubernetes 리소스 타입으로서 Kubernetes 리소스들의 state 변화, 에러 또는 시스템에 특정 메세지를 전파해야할 때 자동으로 만들어진다. 이러한 Kubernetes Events 리소스는 Kubernetes 개발 및 운영하며 디버깅시에 매우 유용하게 사용된다. Events 조회 `kubectl describe pod pod-name`를 사용하면 아랫부분에 Events 항목을 볼 수 있다. 이것이 바로 해당 Pod와 관련된 Kubernetes Events들의 정보를 나타낸다. 특정 Pod 뿐 아니라 현재 namespace 에 발생하는 모든 Events를 조회하고 싶다면 `kubectl get events` 를 통해 조회할 수 있다. 하지만 모

인그레스(ingress)는 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리한다. 인그레스는 부하 분산, SSL 종료, 명칭 기반의 가상 호스팅을 제공할 수 있다. 인그레스는 클러스터 외부에서 클러스터 내부 서비스로 HTTP와 HTTPS 경로를 노출한다. 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다. [인그레스]( 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다.

Labels and Selectors

Labels are key/value pairs that are attached to objects such as Pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects. Labels can be attached to objects at creation time and subsequently added and

Pod는 동일한 실행환경에서 실행되는 애플리케이션 컨테이너와 볼륨으로 구성된 집합체다. 포드는 쿠버네티스 클러스터에서 배포 가능한 가장 작은 아티팩트(artipact)다. 즉, 포드에 있는 모든 컨테이너가 `동일한 머신에 있음`을 뜻한다. Pod에 있는 각 컨테이너는 각자의 `cgroup`을 운영하지만 몇가지 `Linux 네임스페이스`는 공유한다. Pod의 각 컨테이너는 각자의 cgroup 을 운영하지만 몇가지 리눅스 네임스페이스를 공유하며, 서로 다른 파드는 각 애플리케이션이 격리되어 있고 각기 다른 IP주소와 호스트네임을 갖는다. 또한 System V IPC나 POSIX 메시지 큐(IPC 네임스페이스)를 통해 기본 프로세스 간 통신 채널을 사용해 서로 통신할 수 있다. 동일한 노드에서 동작

Pod Readiness and Probes

Pod Readiness는 Pod가 트래픽을 처리할 준비가 되었는지를 나타내는 추가적인 지표이다. Pod Readiness는 외부에서 해당 Pod의 주소가 `Endpoints` 객체에 표시될지 여부를 결정한다. Deployment와 같이 Pod를 관리하는 Kubernetes 리소스들은 롤링 업데이트를 진행할 때 Pod Readiness를 고려하여 의사결정을 한다. 롤링 배포 중에 새 Pod가 Ready 상태가 되었지만 Service, NetworkPolicy, 또는 로드 밸런서가 아직 새 Pod를 받아들일 준비가 되지 않은 경우가 있다. 이로 인해 서비스 중단이나 백엔드 용량 손실이 발생할 수 있다. Pod spec에 아무 Probe도 정의되어 있지 않으면 Kubernetes는 세 가지 Probe 모두 성

Pod 생성과정

관리자가 애플리케이션을 배포하기 위해 ReplicaSet을 생성하면 다음과 같은 과정을 거쳐 Pod을 생성한다. 흐름을 보면 각 모듈은 서로 통신하지 않고 오직 API Server와만 통신하는 것을 알 수 있다. API Server를 통해 etcd에 `저장된 상태를 체크`하고 `현재 상태와 원하는 상태가 다르면 필요한 작업을 수행`한다. 각 모듈이 하는 일을 보면 다음과 같다. kubectl ReplicaSet 명세를 yml파일로 정의하고 kubectl 도구를 이용하여 API Server에 명령을 전달 API Server는 새로운 ReplicaSet Object를 etcd에 저장 Kube Controller Kube Controller에 포함된 ReplicaSet Controller

!image과 PVC라고 하는 퍼시스턴트 볼륨 클레임(PersistentVolumeClaim) 2개로 분리되어 있다. PV/PVC PV는 Persistent Volume의 약자이다. pod와는 별개로 관리되며 별도의 생명 주기가 있다. PVC는 사용자가 PV에 하는 요청이다. 사용하고 싶은 용량은 얼마인지, 읽기/쓰기는 어떤 모드로 설정하고 싶은지 등을 정해서 요청한다. k8s 볼륨을 pod에 직접 할당하는 방식이 아니라 중간에 PVC를 두어

Rolling Update는 k8s의 업데이트 방법 중 하나로, 새로운 버전의 애플리케이션을 배포하고 기존 버전을 점진적으로 대체하는 과정으로 진행된다. 새로운 버전의 Pod로 트래픽이 전달되기 전까지 기존 버전이 유지되므로 무중단으로 애플리케이션을 업데이트 가능한 장점이 있다. 그러나 새로운 버전의 Pod와 기존 Pod가 함께 유지되는 기간이 존재하기 때문에 업데이트 중에 리소스를 더 사용할 수 있다. 기본적으로 Rolling Update는 다음과 같은 단계로 이뤄진다. 1. 새로운 버전의 애플리케이션을 배포한다. 이때 기존 버전은 유지된 상태로 새로운 버전의 Pod가 함께 생성된다. 2. 새로운 버전의 Pod가 정상적으로 동작하고, 준비 상태가 되면, 이전 버전의 Pod을 하나씩 종료한다. 이때

Service와 port

쿠버네티스 환경에서 Service는 Pod들을 통해 실행되고 있는 애플리케이션을 네트워크에 노출(expose)시키는 가상의 컴포넌트다. 쿠버네티스 내부의 다양한 객체들이 애플리케이션과, 그리고 애플리케이션이 다른 외부의 애플리케이션이나 사용자와 연결될 수 있도록 도와주는 역할을 한다. 쿠버네티스에 Service가 있는 이유는, Pod들이 반영속적인 특성을 가지고 있기 때문이다. 쿠버네티스에서의 Pod는 무언가가 구동 중인 상태를 유지하기 위해 동원되는 일회성 자원으로 언제든 다른 노드로 옮겨지거나 삭제될 수 있다. 또한 Pod는 생성될 때마다 새로운 내부 IP를 받게 되므로, 이것만으로 클러스터 내/외부와의 통신을 계속 유지하기 어렵다. 따라서 쿠버네티스는 Pod가 외부와 통신할

![image]( StatefulSets are a workload abstraction in Kubernetes to manage pods like you would a deployment. Unlike a deployment, StatefulSets add the following features for applications that require them: Stable, unique network identifiers Stable, persistent storage Ordered, graceful deployment and scaling

attachdetach controller

Objective Make volume attachment and detachment independent of any single node's availability If a node or kubelet goes down, the volumes attached to that node should be detached so that they are free to be attached to other nodes. Secure Cloud Provider Credentials Because each kubelet is responsible for triggering attach/detach logic, every node currently needs (often broad) permissions. Th

CSIDriver captures information about a Container Storage Interface (CSI) volume driver deployed on the cluster. Kubernetes attach detach controller uses this object to determine whether attach is required. Kubelet uses this object to determine whether pod information needs to be passed on mount. CSIDriver objects are non-namespaced. The CSIDriver Kubernetes API object serves two purposes: 1.

A workload is an application running on Kubernetes. Whether your workload is a single component or several that work together, on Kubernetes you run it inside a set of pods. In Kubernetes, a Pod represents a set of running containers on your cluster. Kubernetes pods have a defined lifecycle. For example, once a pod is running in your cluster then a critical fault on the node where that pod is run

가상 IP와 서비스 프록시

쿠버네티스 클러스터의 모든 노드는 `kube-proxy`를 실행한다. `kube-proxy`는 ExternalName 이외의 유형의 서비스에 대한 "가상 IP"의 역할을 한다. service를 조회했을때 나오는 cluster IP가 바로 k8s의 프록시로 만들어진 가상 IP이다. 이 IP는 k8s 내부에서만 접근할 수 있다. 쿠버네티스에서 가상 IP를 사용하는 이유 쿠버네티스가 프록시를 통해 가상 IP를 만드는 이유는, 실제 IP와 DNS를 사용하기 부적절하기 때문이다. k8s의 서비스 객체는 IP를 할당할 수 있는 기기가 아니고 잠시 생겼다가 사라질 수 있는 유한한 존재이다. 하지만 서비스를 식별하고 호출할 수 있는 무언가가 필요하기 때문에 그 방법으로서 프록시로 만든 가상 IP를 사용

사이드카 패턴

사이드카 패턴이란 쿠버네티스와 같이 컨테이너 오케스트레이션 툴에서 구성할 수 있는 컨테이너 배치 패턴으로, 마치 오토바이 옆에 붙어 있는 사이드카와 비슷한 형태이다. 장점 1. 기존 로직의 변경 없이 기능 추가 사이드카 컨테이너를 통해 기존의 로직은 그대로 놔둔체 새로운 기능을 덧붙일 수 있다. 예를 들어 기존 http 프로토콜에 대해서만 서비스를 하는 웹서버에 tls layer를 추가하고 싶은 경우, 메인 컨테이너인 기존의 legacy 웹서버는 그대로 놔둔체 사이드카 컨테이너를 통해 https 서비스를 클라이언트에게 제공할 수 있다. 2. 컨테이너 재사용성 사이드카 컨테이너를 단일한 기능을 하게 모듈화하면 다른 곳에서 재사용하기 수월해진다. 대부분의 app에서는 로깅, 실행 프로세스 정보 확

10 most common mistakes using kubernetes

1. resources requests와 limits CPU request는 보통 설정하지 않거나 매우 낮게 설정하여(각 노드에 많은 Pod를 배치하기 위해) 노드가 오버커밋 상태가 된다. 높은 부하 시 노드의 CPU가 완전히 사용되면 워크로드는 "요청한 만큼"만 받게 되어 CPU 쓰로틀링이 발생하고, 애플리케이션 레이턴시 증가, 타임아웃 등의 문제가 생긴다. 반면 CPU limit은 노드의 CPU가 완전히 사용되지 않더라도 Pod를 불필요하게 쓰로틀링하여 레이턴시를 증가시킬 수 있다. Linux 커널의 CPU CFS 할당량과 설정된 CPU limit 기반 쓰로틀링, CFS 할당량 비활성화에 대한 논의가 진행 중이다. CPU limit은 해결하는 것보다 더 많은 문제를 일으킬 수

k8s에서 kubectl과 같은 커맨드를 사용해 API를 요청하는 과정은 크게 3가지로 구성되어 있다. 1. 'k8s 사용자가 맞느냐'를 판단하는 Authentication 2. 두 번째는 'API를 호출할 수 있는 권한이 있느냐'를 판단하는 Authorization 3. 마지막으로 그 요청이 적절한지를 판단하는 Admission Controller이다. Authorization와 Admission Controller는 k8s에 내장되어 있는 기능이기 때문에 사용 방법이 비교적 정해져 있는 반면, 첫 번째 단계인 Authentication은 이렇다 할 정답이 딱히 정해져 있지 않다. 물론 k8s의 자체 인증 기능인 ServiceAccount, 인증서 등을 사용할 수는 있지만, 사내에서 LADP, Go

k8s 클러스터 root CA를 통한 사용자 인증

k8s는 기본적으로 root CA 인증서를 스스로 발급해 사용한다. 이 인증서를 이용하면 별도의 Third-party 연동 없이도 User와 Group을 사용할 수 있다. 단, 이 방법은 여러모로 한계점이 많기 때문에 가능하면 사용하지 않는 것이 좋다. 인증서가 유출되었을 때 revoke가 힘들기도 하고, 파일 단위로 인증 정보를 관리하는 것은 매우 비효율적이고 보안에 취약하기 때문이다. 따라서 k8s는 인증서 발급을 통한 사용자 인증은 극히 제한된 경우에만 사용하고 있다. 대표적으로는 관리자 권한을 가져야 하는 `system:master` 그룹의 인증 정보를 생성한다거나 (`/etc/kubernetes/admin.conf`), k8s의 핵심 컴포넌트에 인증서를 발급한다거나 할 때가 이에 해당한다. 우선

OIDC Authentication with Dex

OIDC (Open ID Connect) 인증 방법은 OAuth2 위에서 동작하는 인증으로, Github이나 Google과 같이 서드 파티에서 부여받은 OAuth 권한을 통해 쿠버네티스의 인증을 수행한다. 기존에 사용하던 OAuth 인증 방법을 쿠버네티스에 그대로 가져온다고 생각하면 이해하기 쉽다. OIDC 인증 방법은 OAuth + JWT 토큰을 사용한다는 점에서 Webhook Token 인증 방법과 차이점을 갖는다. OAuth 토큰을 관리하기 위한 중간 서버를 구현한 [Dex]( 사용하여 OIDC 인증을 구현해보자. Dex Concept Dex는 서드 파티로부터 OAuth 인증 토큰을 가져와 관리하는 인증 도구이다. OAuth를 사용하기 위

Security Context for a Pod or Container

A security context defines privilege and access control settings for a Pod or Container. Security context settings include, but are not limited to: Descretionary Access Control: Permission to access an object, like a file, is based on user ID (UID) and group ID (GID)](

Token Webhook with Guard

Webhook 서버에 인증 데이터를 전달한 뒤, 클라이언트가 유효한지 인증하여 Third party에 권한을 부여하는 Webhook Token 인증 방법에 대해 알아보자. 1. 사용자는 미리 인증 데이터를 발급받아 놓고, 2. 사용자가 인증 데이터를 Bearer 헤더에 담아서 REST API 요청을 보내면 3. API 서버는 클라이언트가 유효한지를 검증하기 위해 Webhook 서버에 인증 데이터를 전달한다. 4. Webhook 서버는 해당 데이터를 검사한 뒤, 인증 여부를 API 서버에 반환하는 간단한 방식으로 되어 있다 Token Webhook, OIDC 중 어느 방법을 선택하든지에 상관 없이 클라이언트는 HTTP의 Bearer 헤더에 인증 데이터를 담아서 보내기만 하면 된다. 클라이언트는 인증

kubernetes 에서 ingress 상에서 https를 서비스하는데 지원을 해주는 모듈이다. cert manager 설치 bash kubectl create namespace cert-manager kubectl apply --validate=false -f or kubectl apply --validate=false -f kubectl create namespace cert

Let's set up role-based access control (RBAC) suitable for running the cluster in production. We will cover roles for using Calico. General RBAC for a production Kubernetes cluster is beyond the scope of this lab. Using `calicoctl` In order for the `calicoctl` tool to perform version mismatch verification (to make sure the versions for both the cluster and `calicoctl` are the same), whoever is

K8s를 위한 SpringBoot 개발

참고: Dockerize Spring Boot Application을 dockerize 하는 방법은 대표적으로 Jib, Buildpacks, Dockerfile 세가지가 있다. 이 중 Jib는 build time이 빠르고 (효율적인 layering), image 사이즈를 가장 작세 만들 수 있다는 장점을 가지고있다. Jib의 사용법은 간단하다. 아래와 같이 `build.gradle`에 jib gradle plugin을 추가하면 된다. groovy plugins { id 'com.google.cloud.tools.jib' version '3.2.0' } 그

kubectl context

쿠버네티스 클러스터를 관리하는 cli 도구인 kubectl에는 환경을 바꿔가며 클러스터를 관리할 수 있도록 "context"라는 개념이 존재한다. context 는 kubectl 을 깔면 생성되는 파일인 `~/.kube/config` 파일에서 설정할 수 있다. yml apiVersion: v1 clusters: cluster: insecure-skip-tls-verify: true server: name: local-cluster cluster: certificate-authority-data: ~~~~ server: name: gcp-cluster users: name: loca

minukube 시작하기

1. kubectl을 설치한다. 버전은 1.22로 통일한다. linux 기준 명령어는 다음과 같다. bash curl -o kubectl mac 기준 명령어는 다음과 같다. bash curl -o kubectl window 기준 명령어는 다음과 같다. bash curl -o kubectl.exe

NetworkPolicy Cilium example

Using the same KIND cluster from the Cilium install, let's deploy the Postgres database([database.yaml]( with the follwing `YAML` and `kubectl` bash $ kubectl apply -f database.yaml service/postgres created configmap/postgres-config created statefulset.apps/postgres created Here we deploy our web se

Pulling images from ECR on Kubernetes

If you are getting the HTTP 403 (Forbidden) error or the error message no basic auth credentials when trying to pull an image from ECR you are most likely doing so without logging into it first. This is going to happen if we are running a Kubernetes cluster on EC2 instances instead of using EKS. To be able to authenticate before pulling images on Kubernetes we need to use the imagePullSecrets att

SpringBoot 서비스를 위한 Kubernetes 설정

출처: Deployment 아래는 deployment설정의 예시이다. yml apiVersion: apps/v1 kind: Deployment metadata: name: main-server labels: app: main-server spec: selector: matchLabels: app: main-server template: metadata: labels: app: main-server spec: affinity: podAntiAffinity: preferr

환경변수 설정

포드의 구성 파일 안에서 정의한 환경 변수는 파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이, 구성 파일 안의 다른 곳에서 사용할 수 있다. 아래의 구성 파일 예시에서, GREETING, HONORIFIC, 그리고 NAME 환경 변수들이 각각 Warm greetings to, The Most honorable, 그리고 Kubernetes로 설정되어 있다. 이 환경 변수들은 이후 env-print-demo 컨테이너에 전달되어 CLI 인자에서 사용된다. yml apiVersion: v1 kind: Pod metadata: name: print-greeting spec: containers: name: env-print-demo image: bash env: name

💡 APM, log, Infrastructure를 통합적으로 모니터링·관리하는 클라우드 모니터링 솔루션 여러 클라우드 환경에 나뉘어있는 리소스들을 통합적으로 모니터링 가능하다. 클라우드의 상태를 지속적으로 감시하여 예기치 못한 상황과 오류를 대비, 대응할 수 있다. 장점 에러를 빠르게 확인하여 신속한 대응 가능 애플리케이션 정보(log, query 등) 축적하여 데이터 기반 개선 개발자, 운영팀, 비즈니스 유저간 긴밀한 협업 다양한 언어과 환경을 지원하기 때문에, 원하는 애플리케이션에 확장 가능 커스텀 대시보드 생성 가능 공식 문서가 친절함 단점 비용이 많이 든다. 기능이 많아서 실무에 도입하기 위해 사전 지식이 필요함. --- Datadog의 주

datadog APM 기능 사용하기

서버에 datadog agent를 설치하면 CPU 점유율, Memory, Disk사용량 등의 중요한 성능 정보를 모니터링할 수 있다. 하지만 애플리케이션의 전반적인 LifeCycle에 대한 리포트 (ex: GC, JVM, I/O 등)를 바탕으로 에러나 병목현상에 더 빠르게 대응할 수 있도록 하고싶다면 Datadog APM을 연결해야한다. APM 이란? Application Performance Monitoring 의 약자로 구동 중인 애플리케이션의 대한 성능측정과 에러탐지 등, 전반적인 애플리케이션 라이프사이클의 정보를 수집해 모니터링할 수 있게 해준다. 보다 편리성을 위해서 다양하게 시각화한 Metrics, 그리고 API 테스트도 지원한다. 여러 대의 애플리케이션에 설치가 가능하며 이를 한꺼

datadog 아키텍처

1. Datedog Agent가 하는 일 (Application에서 서버로) Datedog 사용은 아래와 같은 흐름으로 진행된다. ☝🏻 Datadog 사용 흐름 3단계1. 서버에 Datadog agent를 설치한다. (api키 입력)2. agent가 서버나 애플리케이션의 정보를 수집하여 Datedog 서버로 보낸다.3. 유저가 웹에서 대시보드를 확인한다. Datadog Agent가 어떤 일을 하는지, Agent는 어떤 구조로 구성되어있는지 알아보자. Datadog agent 서버에 설치된 *agent는* 해당 서버의 시스템 정보를 수집하여 Datadog 서버로 전송한다. 추가적인 설정을 통해 DB, 메모리 스토어 등에서 추가적인 메트릭을 수집할 수 있다. (APM) SNM

helmChart로 Agent 설치

1. helm을 설치한다. 맥에서는 `brew install helm`을 통해 설치할 수 있고, 윈도우에서는 Chocolatey, 리눅스에서는 Snap에서 패키지를 다운받으면 된다. 또는 바이너리 릴리즈를 다운받아서 직접 설치하는 방법도 있다. 자세한 것은 공식문서에서 확인해보자. 2. Datadog Operator Datadog Operator를 Helm을 통해 설치하는 명령어는 다음과 같다. bash $ helm repo add datadog $ helm install -n datadog --create-namespace --set fullnameOverride="dd

확장성이 뛰어난 오픈 소스 전체 텍스트 검색 및 분석 엔진 대량의 데이터를 신속하고 거의 실시간으로 저장, 검색 및 분석 일반적으로 복잡한 검색 기능과 요구 사항이 있는 응용 프로그램을 구동하는 기본 엔진 / 기술 핵심 개념 Near Realtime (NRT) Elastic Search는 거의 실시간 검색 플랫폼 문서를 색인할 때부터 검색 기능할 때까지 약간의 대기시간(일반적으로 1초)이 매우 짧음 클러스터(Cluster) 전체 데이터를 함께 보유하고 모든 노드에서 연합 인덱싱 및 검색 기능을 제공하는 하나 이상의 노드(서버) 모음 -노드의 그룹이라고 생각 클러스터는 기본적으로 elasticsearch 라는 고유한 이름으로 식별 이 이름은 노드가 이름으로 클러스터에 참

ElasticSearch 검색 명령어

Elasicsearch 검색 명령어 클러스터 상태 (Health) 클러스터가 어떻게 진행되고 있는지 기본적인 확인 클러스터 상태를 확인하기 위해 `_cat` API를 사용 curl를 사용하여 수행 가능 -노드 정보: GET `/_cat/nodes?v` 상태 정보 : GET `/_cat/health?v` Elasticsearch에서 _언더바가 붙은 것들이 API v는 상세하게 보여달라는 의미 녹색 : 모든 것이 정상 동작 노란색 : 모든 데이터를 사용 가능하지만 일부 복제본은 아직 할당되지 않음(클러스터는 완전히 동작) 빨간색 : 어떤 이유로든 일부 데이터를 사용 불가능(클러스터가 부분적으로만 동작) 데이터베이스(index)가 가진 데이터 확인하기 index는 일반 RDB에서의 DB 역할 모

ELK는 Elasticsearch, Logstash 및 Kibana, 이 오픈 소스 프로젝트 세 개를 뜻하는 약자이다. Elasticsearch : 검색 및 분석 엔진 Logstash : 여러 소스에 동시에 데이터를 수집하여 변환한 후 Elasticsearch 같은 “stash”로 전송하는 서버 사이드 데이터 처리 파이프라인 Kibana : 사용자가 Elasticsearch에서 차트와 그래프를 이용해 데이터를 시각화 여기에 데이터 수집기인 Beats를 추가한 것을 ELK Stack이라고 한다. Beats를 추가하면 다른 서버에서 데이터를 가져오는 것도 가능해진다. ubuntu 기준으로 elk를 구축해보겠다. Elasticsearch 설치 bash 설치 wget

Logstash는 실시간 파이프라인 기능을 가진 데이터 수집 엔진 오픈소스이다. Logstash는 서로 다른 소스의 데이터를 동적으로 통합하고 원하는 대상으로 데이터를 정규화 할 수 있는 능력을 가진다. 다양한 입력과 필터 및 출력 플러그인을 통해, 모든 유형의 이벤트를 보강하고 변환할 수 있으며, 많은 기본 코텍이 처리 과정을 단순화한다. 따라서 Logstash는 더 많은 양과 다양한 데이터를 활용하여 통찰력 있게 볼 수 있게 해 준다. Logtash 파이프라인 Logstash의 전체적인 파이프라인에는 INPUTS과 FILTERS, 그리고 OUTPUT이 있다. 이 중에서 2가지의 필수적인 요소는 INPUTS과 OUTPUTS이고, 파싱 여부에 따라 필터는 선택적으로 사용이 가능하다. L

[Grok]( is a tool to parce crappy unstructured log data into something structured and queryable. Grok is heavily used in Logstash to provide log data as input for ElesticSearch. Grok ships with about 120 predefined patterns for syslog logs, apache and other webserver logs, mysql logs, etc. It is easy to extend Grok with cu

Loki Canary is a standalone app that audits the log-capturing performance of a Grafana Loki cluster. Loki Canary generates artificial log lines. These log lines are sent to the Loki cluster. Loki Canary communicates with the Loki cluster to capture metrics about the artificial log lines, such that Loki Canary forms inforation about the performance of the Loki cluster. The information is availa

kiali with prometheus

Kiali requires Prometheus to generate the topology graph, show metrics, calculate health and for several other features. If Prometheus is missing or Kiali can’t reach it, Kiali won’t work properly. By default, Kiali assumes that Prometheus is available at the URL of the form http://prometheus.:9090, which is the usual case if you are using the Prometheus Istio add-on. If your Prometheus instance

Prometheus는 오픈소스 시스템 모니터링 및 알림 툴킷이다. Prometheus는 메트릭을 시계열 데이터로 수집하고 저장한다. 즉, 메트릭 정보는 기록된 타임스탬프와 함께 저장되며, label이라고 불리는 선택적 key-value 쌍도 함께 저장된다. 순수한 숫자 시계열을 기록하는 데 적합하다. 높은 동적성을 가진 서비스 지향 아키텍처의 머신 중심 모니터링에 잘 맞는다. 마이크로서비스 환경에서 Prometheus의 다차원 데이터 수집 및 쿼리 지원은 특히 강력한 장점이다. Prometheus는 안정성을 위해 설계되었으며, 장애 발생 시 문제를 신속하게 진단할 수 있도록 돕는 시스템이다. 각 Prometheus 서버는 독립적으로 동작하며, 네트워크 스토리지나 다른 원격 서비스에 의존하지 않는다.

prometheus agent mode

The core design of Prometheus is inpired by Google's [Borgmon monitoring system]( you can deploy a Prometheus server alongside the applications you want to monitor, tell Prometheus how to reach them, and allow to scrape the current values of their metrics at regular intervals. Such a collection method, which is often referred to

prometheus glossary

Core Prometheus Prometheus usually refers to the core binary of the Prometheus system. It may also refer to the Prometheus monitoring system as a whole. Target A target is the definition of an object to scrape. For example, what labels to apply, any authentication required to connect, or other information that defines how the scrape will occur. Endpoint A source of metrics

prometheus storage

Prometheus는 기본적으로 로컬 디스크 기반의 시계열 데이터베이스를 내장하고 있다. 구조 2시간 단위의 블록(block) 으로 샘플 데이터를 그룹화하여 저장한다. 각 블록은 디렉터리 하나로 구성되고, 아래와 같은 구조를 가진다. `chunks/` 하위 디렉터리: 해당 시간 구간의 시계열 샘플 데이터 chunks 디렉터리 안의 데이터는 기본적으로 최대 512MB 크기의 segment 파일들로 구성된다. `index`: 메트릭 이름 및 라벨 → 시계열 매핑 정보를 담고 있음 `meta.json`: 블록의 메타데이터 `tombstones`: 삭제 요청된 시계열 정보를 별도로 기록 (바로 삭제하지 않음) WAL (Write-Ahead Log, 선기록 로그) 최신 샘플 데이터는 아직

Telemetry automatically collects, transmits and measures data from remote sources, using sensors and other devices to collect data. It uses communication systems to transmit the data back to a central location. Subsequently, the data is analyzed to monitor and control the remote system. Collecting telemetry data is essential for administering and managing various IT infrastructres. Th

Contour is an Envoy based ingress controller. And it is an open source Kubernetes ingress controller providing the control plane for the Envoy edge and service proxy. Contour supports dynamic configuration updates and multi-team ingress delegation out of the box while maintaining a lightweight profile. Getting Started with Contour Let's look at three ways to install Contour using Contou

Contour CRD 설치

Install Contour: Use the appropriate command for your cluster manager to install Contour. For example, using kubectl for Kubernetes: bash kubectl apply -f This command downloads and applies the Contour manifest file, which includes the necessary resources for Contour's installation. Verify Contour installation: Check that the

Envoy is a high performance C++ distributed proxy designed for single services and applications, as well as a communication bus and “universal data plane” designed for large microservice “service mesh” architectures. Built on the learnings of solutions such as NGINX, HAProxy, hardware load balancers, and cloud load balancers, Envoy runs alongside every application and abstracts the networ

The listener discovery service (LDS) is an optional API that Envoy will call to dynamically fetch listeners. Envoy will reconcile the API response and add, modify, or remove known listeners depending on that is required. The semantics of listener updates are as follows: Every listener must have a unique name. If a name is not provided, Envoy will create a UUID. Listeners that are to be synamical

xDS configuration

Envoy is architected such that different types of configuration management approaches are possible. The approach taken in a deployment will be dependent on the needs of the implementor. Simple deployments are possible with a fully static configuration. More complicated deployments can incrementally add more complex dynamic configuration, the downside being that the implementor must provide one or

location 블록은 Nginx에서 정의되어 있는 웹사이트의 특정 URL 을 조작하는데 사용되는 블록이다. Server 블록마다 Location 을 지정해줄 수 있으며, Location 을 여러 번 정의할 수 있다. location은 URI 경로의 일부인 prefix string이거나 정규식 표현이 될 수 있다. 예시 bash // nginx.conf server { location /images/ { root /data; } location / { proxy_pass http://www.example.com; } } 위와 같이 server 내부에 표시해준다. 위의 코드는 첫 번째 location context와 일치하는 패

nginx에서 https를 적용하기 위해 certbot과 Let's encrypt를 사용해보자. 일단 nginx를 아래와 같이 설정해준다. bash server { listen 80; server_name your.domain.com; location / { proxy_pass http://192.168.XXX.XXX; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; } } 1. certbot 설치 bas

1. nginx 컨테이너 실행 jsx sudo docker run --name nginx -d -p 80:80 nginx 1. nginx bash 들어가서 conf 파일 열기 jsx docker exec -it nginx bash vi /etc/nginx/conf.d/default.conf 1. 원하는 도메인, 포트 설정해넣기 예시 jsx server { listen 80; listen [::]:80; server_name domain.aliens-dms.com; location / { proxy_pass http://ip:8080; } } 1. nginx reload로 적용 j

NGINX Ingress Basic Auth

NGINX Ingress에서 설정을 해주면 어플리케이션 레벨에서, 혹은 Ingress 레벨에서 서비스 인증과정을 거치도록 할 수 있다. ingress를 통해 인증을 설정하는 방법을 두가지 알아보자. ![image]( Static User Static User는 미리 basic auth로 인증할 유저 리스트를 생성하고 해당 리스트에 포함된 인원만 인증될 수 있게 하는 방법이다. 별다른 추가 작업 없이 사용자

nginx 명령어

Nginx 시작 bash sudo systemctl start nginx Nginx 시작 (systemd 없이 Linux 배포를 실행하는 경우) bash sudo service nginx start Nginx 중지 bash sudo systemctl stop nginx sudo service nginx stop Nginx 다시 시작 bash sudo systemctl restart nginx sudo service nginx restart Nginx reroad (새 설정을 적용해야할 떄) bash sudo systemctl reload nginx sudo service nginx reload Nginx 구성 테스트 설

Nginx를 설치한다. 원하면 이미지로 띄울 수도 있다. bash $ sudo apt update $ sudo apt install nginx 설정 파일 생성 $ cd /etc/nginx/conf.d $ vim default.conf default.conf 파일을 생성하고 아래와 같이 원하는 설정 내용을 적어준다. bash server { listen 80; server_name your.domain.com; location / { proxy_pass http://192.168.XXX.XXX; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-

sites available

bash ubuntu@:~/ cd /etc/nginx `/etc/nginx`의 경로에서 nginx에 대한 기본적인 설정을 진행할 수 있다. 그 중 프록시 관련 설정을 할 때 bash /etc/nginx/sites-enabled 라는 폴더에서 직접적으로 설정이 가능하고 유저는 저 폴더에 있는 설정파일을 직접적으로 수정하지 않고 bash /etc/nginx/sites-available 의 폴더에서 여러 설정파일들을 생성한 뒤 symlink 기능을 이용해서 그 파일들 중 원하는 설정을 선택적으로 `sites-enabled`폴더에 동기화해서 적용할 수 있다. 다음은 sites-available에 만든 설정파일을 sites-enabled에 symlink 시킬 수

리버스 프록시

클라이언트 요청을 대신 받아 내부 서버로 전달해주는 것을 리버스 프록시(Reverse Proxy)라고 한다. 리버스 프록시가 필요한 이유 로드 밸런싱 : Nginx는 클라이언트의 요청을 프록시 서버에 분산하기 위해 로드 밸런싱을 수행하여 성능, 확장성 및 신뢰성을 향상시킬 수 있다. 캐싱 : Nginx를 역방향 프록시로 사용하면 미리 렌더링된 버전의 페이지를 캐시하여 페이지 로드 시간을 단축할 수 있다. 서버의 응답에서 수신한 콘텐츠를 캐싱하고 이 콘텐츠를 사용하여 매번 동일한 콘텐츠를 프록시 서버에 연결할 필요 없이 클라이언트에 응답하는 방식으로 구현하는게 가능해진다. SSL 터미네이션 : Nginx는 클라이언트와의 연결에 대한 SSL endpoint 역할을 할 수 있다. 압축 : 프록시 서

Reverse Proxy vs. Ingress Controller vs. API Gateway

Reverse Proxy You can think of the reverse proxy as that old-school phone operator, you know, back when there used to be call centers and phone operators. Back then, when someone was picking up the phone, they were connected to a call center, the caller stated the name and the address of the person they wanted to call, and the phone operator connected them. A reverse proxy does a similar job by

Cilium is open source software for transparently securing the network connectivity between application services deployed using Linux container management platforms like Docker and Kubernetes. At the foundation of Cilium is a new Linux kernel technology called [eBPF](

![image]( MinIO는 GNU Affero General Public License v3.0 하에 배포되는 고성능 객체 스토리지이다. Amazon S3 클라우드 스토리지 서비스와 API가 호환되며, 머신러닝, 분석, 애플리케이션 데이터 워크로드를 위한 고성능 인프라 구축에 사용된다. 아키텍처 각 MinIO Tenant는 Kubernetes 클러스터 내 독립적인 객체 스토어이다. 아래 다이어그램은 Kubernetes에 배포된 MinIO Tenant의 아키텍처다: ![image](

Mortar는 Linux의 물리적 보안 구성 요소들을 연결하는 프레임워크다. Mortar 모델을 통해 디스크에서 사용되는 모든 것이 암호화되거나, 서명되거나, 해시된다. 평문 시크릿이 저장되는 유일한 위치는 TPM 모듈이다. TPM은 특정 부팅 상태를 효과적으로 화이트리스트하는 데 사용되며, Mortar는 변조되지 않은 시스템이 감지될 때만 키를 해제하도록 구성한다. 이 검증 및 잠금 해제 프로세스가 완전히 자동화되어 있어서, 정상적인 시스템은 사용자 개입 없이 완전히 재시작된다. 덕분에 전체 디스크 암호화가 최종 사용자에게 훨씬 편리해지고, 서버에서도 실용적으로 사용할 수 있게 된다. 동작 방식 기본 디스크에서는 2개의 파티션만 사용된다: UEFI ESP와 암호화된 LUKS 파티션이

![image]( openHistorian is a back-office system developed by the GridProtectionAlliance that is designed to efficiently integrate and archive process control data, such as SCADA, synchrophasor, digital fault recorder, or any other time-series data used to support process operations. It is optimized to store and

Packer ( 는 HashiCorp에서 개발한 가상 머신 이미지를 만들어주는 오픈소스이다. 예를 들어서, 아마존 클라우드 AMI이미지나, 구글 클라우드 이미지를 스크립트를 이용하여 생성이 가능하다. 하나의 스크립트를 이용하여, 구글 클라우드, VMWare, 아마존 클라우드 등 여러 클라우드 환경 (가상화 환경)과 컨테이너 엔진용 이미지를 생성할 수 있다. Chef, Puppet, Ansible과 같은 Configuration management 툴과 혼동이 될 수 있지만, Packer는 OS 이미지를 만들어주는 역할을 하고, Configuration management 툴들은 이렇게 만들어진 이미지 위에 소프트웨어를 설치하고, 이를 설정하는 상호 보완적인 역

DevOps는 `development`와 `operations`가 합쳐진 단어이며, 소프트웨어 개발과 배포 프로세스를 자동화하고 통합하는 개발방법론, 철학이다. 팀 지원, 팀 간 커뮤니케이션 및 공동 작업, 기술 자동화를 강조한다. DevOps는 소프트웨어 제공 프로세스를 효율적으로 수행하는 것을 목표로 한다. 이를 위해 워크플로를 자동화하고 신속하게 피드백하여 프로젝트를 더 잘 제어할 수 있도록 하는 여러 방법을 사용한다. DevOps 문화 철학 DevOps에서는 개발과 운영이라는 두 팀간의 장벽을 없애 개발자의 생산성과 운영의 안정성을 모두 최적화한다. 두 팀은 자주 소통하고, 효율성을 높이고, 고객에게 제공하는 서비스의 품질을 향상하기 위해 최선을 다한다.