Skip to content

태그: Kubernetes

총 112개의 글이 있습니다.

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

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다. 그런데 Se

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

Karpenter best practices

Use Karpenter for workloads with changing capacity needs Karpenter는 Auto Scaling Groups (ASG)나 Managed Node Groups (MNG)보다 Kubernetes 네이티브 API에 더 가까운 스케일링 관리를 제공한다. ASG와 MNG는 AWS 네이티브 추상화로, EC2 CPU 부하와 같은 AWS 레벨 메트릭을 기반으로 스케일링이 트리거된다. Cluster Autoscaler는 Kubernetes 추상화를 AWS 추상화로 연결하지만, 특정 가용 영역에 대한 스케줄링과 같은 일부 유연성을 잃는다. Karpenter는 AWS 추상화 레이어를 제거하여 유연성을 Kubernetes에 직접 제공한다. Karpenter는 높고 급격한 수요를 겪

큐 메세지 갯수 등 지정한 메트릭에 따라 스케일링하기 위해 사용 SacaledObject apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetadata: name: demo namespace: inflearnspec: scaleTargetRef: name: demo apiVersion: {api-version-of-target-resource} Optional. Default: apps/v1 kind: {kind-of-target-resource} Optional. Default: Deployment triggers:

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

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 sourc

Argo Workflow Priority

1. Controller에서 Priority 추출 (controller.go) func getWfPriority(obj interface{}) (int32, time.Time) { un, ok := obj.(*unstructured.Unstructured) if !ok { return 0, time.Now() } priority, hasPriority, err := unstructured.NestedInt64(un.Object, "spec", "priority") if err != nil { return 0, un.GetCreationTimestamp().Time } if !hasPriority { priority = 0 }

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 역할을 하여 서명된 인증서를 반환 프록시 간 통신에 필요한 TLS 신

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

Terminal window 기본 kubeconfig 사용$ k9s 기본이 아닌 kubeconfig 사용$ k9s --kubeconfig /path/to/kubeconfig 기본이 아닌 context 사용$ k9s --context fooctx 읽기 전용 모드$ k9s --readonly 정보 확인 (설정, 로그, 화면 덤프 위치)$ k9s info 리소스 목록 조회 특정 리소스 목록 조회: :&x3C;resource>: 리소스 목록 조회, 예: 모든 Pod 목록 조회하려면 :pod :&x3C;resource&x3C;namespace>: 특정 네임스페이스의 리소스 목록 조회: 리소스 목록 조회, 예: 모든 Pod 목록 조회하려면 :pod : : 특정 네임스페이스의 리소스 목록 조회">

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

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

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 Plu

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

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

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(HPA) 와 VerticalPodAutoscaler(

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”. De

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. After you identify the cluster creator or admin, configure AWS CLI to use the cluster creator IAM. See Configuration basics for

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 netwo

If you want to persist your own data to EBS in EKS environment, you can use EBS CSI driver addon provided by AWS. Beforehand we need to enable the IAM OIDC provider and create the IAM role for the EBS CSI driver. The easiest way to do both is to use eksctl (other ways like using plain aws cli or the AWS GUI are described in the docs). 1. Enable IAM OIDC provider A prerequisite for the EBS CSI driv

When you create a Kubernetes ingress, an AWS Application Load Balancer (ALB) is provisioned that load balances application traffic. ALBs can be used with Pods that are deployed to nodes or to AWS Fargate. You can deploy an ALB to public or private subnets. Before you can load balance application traffic to an application, you must meet the following requirements. Prerequisites Have an existing c

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 p

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(CNI) plugins for cluster networking. Amazon EKS officially supports VPC CNI plugin to implement Kubernetes Pod networking. The VPC CNI provides native integra

EKS 기본 환경 Setting 방법을 알아보자. 쿠버네티스는 kubectl에 대한 인증정보를 kubeconfig라는 yaml파일에 저장한다. EKS 클러스터는 어떻게 접근을 하는지, 어떻게 인증을 받아오는지 알아보자. Kubeconfig EKS 클러스터에 접근 가능한 kubeconfig파일을 생성하는 것은 간단하다. aws command 한 줄이면 인증 정보를 kubeconfig 파일에 저장할 수 있다. Terminal windowaws eks --region &x3C;region-code> update-kubeconfig --name &x3C;cluster_name> update-kubeconfig --name "> kubeconfig 파일 내용을 살펴보자. apiVersion: v1clusters:cl

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을 Encoding하여 Tok

IP addresse prefix

Each Amazon EC2 instance supports a maximum number of elastic network interfaces and a maximum number of IP addresses that can be assigned to each network interface. Each node requires one IP address for each network interface. All other available IP addresses can be assigned to Pods. Each Pod requires its own IP address. As a result, you might have nodes that have available compute and memory res

AWS Load Balancer Controller supports Network Load Balancer (NLB) with IP tergets for pods runing on Amazon EC2 instances and AWS Fargate through Kubernetes service of type LoadBalancer with proper annotation. In this mode, the AWS NLB targets traffic directly to the Kubernetes pods behind the service, aliminationg the need for an extra network hop through the worker nodes in the Kubernetes cluste

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 with the kub

K8s Architecture

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

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

Kubernetes Overview Diagrams

두개의 포드와 서비스가 있다고 해보자. 각 포드의 이름은 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 자격 증명 공급자를 생성한다. Terminal windoweksctl 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 가 생성이 되었는데, 클러스터내의

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 apiVersion: v1kind: Podmetadata: name: dnsutils namespace: defaultspec: containers: name: dnsutils

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

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

Network Troubleshooting

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

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 creati

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

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 helps

Terminal windowistioctl proxy-statusNAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSIONargocd-application-controller-0.argocd Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-977466b69-2kms7 1.18.2argocd-applicationset-contr

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 followi

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 run the

Istio RBAC를 통해 네임스페이스, 서비스, HTTP 메소드 수준의 권한 제어를 실습 해보자. 준비작업 k8s, helm 설치 Istio 초기화 (namespace, CRDs) Terminal window$ 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 | kubectl appl

Istio authorization

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

Resource Annotations & Labels

The various resource annotations that Istio supports to control its behavior.

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 builds

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 modi

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 fo

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

Karpenter best practices

Use Karpenter for workloads with changing capacity needs karpenter brings scailing management closer to Kubernetes native APIs than do Autoscaling Groups (ASGs) and Managed Node Groups (MNGs). ASGs and MNGs are AWS-native abstractions where scaling is triggered based on AWS level metrics, such as EC2 CPU load. Cluster Autoscaler bridges the Kubernetes abstractions into AWS abstractions, but loses

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 sp

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 names

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

Node Termination Handler

Node Termination Handler는 EC2 인스턴스가 EC2 maintenance events, EC2 Spot interruptions, ASG Scale-In, ASG AZ 재조정, and EC2 Instance Termination 등의 이유로 사용할 수 없는 상태가 되었을 때 대응하기 위한 tool이다. 그에 대한 핸들링을 제때 해줌으로써 Pod를 더 빠르게 회복시키고 availability를 높일 수 있다. modes The aws-node-termination-handler(NTH)에는 Instance Metadata Service (IMDS) 모드와 Queue Processor 모드 두가지가 있다. IMDS mode The aws-node-termination-handler Insta

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 policies. These policies may be there to meet governanc

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 pass t

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

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 (such a

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

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 In above

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를 설정할 수 있다. service selec

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

K8s의 도커런타임 사용중단

Source : 쿠버네티스는 버전 v1.20 이후 Docker를 컨테이너 런타임으로서 사용하지 않겠다고 알렸다.(2020.12.02) GKE 및 EKS 등의 관리 Kubernetes 서비스를 사용하는 경우 오퍼레이터에서 지원되는 버전의 런타임을 사용하는 것을 확인하고 쿠버네티스 릴리스에서 도커 지원이 만료되기 전에 변경 해야한다. 자세한 내용은 아래와 같다. DeprecationDocker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a modul

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 IP addre

NodePort와 ServicePort와 targetPort

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

Assigning Pods to Nodes

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 a

Taints and Tolerations

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 parameters a

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

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: Simplif

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. The

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 runn

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를 순서대로 처리하는

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, the

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

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 down

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 upgrade a D

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

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 modi

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

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

Pod Readiness and Probes

Pord readiness is and additional indication of whether the pod is ready to serve traffic. Pod readiness determines whether the pod address shows up in the Endpoints object from an external source. Other Kubernetes resources that manage pods, like depolyments, take pod readiness into account for decision-making, such as advancing during a rolling update. During rolling deployment, a new pod becomes

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가 Replica

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

Service와 port

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

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 Ordered, automated rolling updates The deployment resource is better suited for applications that d

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

가상 IP와 서비스 프록시

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

사이드카 패턴

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

10 most common mistakes using kubernetes

We had the chance to see quite a bit of clusters in our years of experience with Kubernetes (both managed and unmanaged on GCP, AWS and Azure), and we see some mistakes being repeated. No shame in that, we’ve done most of these too! Let’s try to show the ones we see very often and talk a bit about how to fix them. 1. resources requests and limits CPU request are usually either not set or sey ver

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

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를 사용하기 위해 반드시 Dex를 써야 하는 것은 아니지만, Dex는 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). Security Enhanced Linux (SELinux): Objects are assigned security labels. Running as privileged or unprivileged. Linux Capabilities

Token Webhook with Guard

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

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

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

kubernetes 에서 ingress 상에서 https를 서비스하는데 지원을 해주는 모듈이다. cert manager 설치 Terminal windowkubectl create namespace cert-managerkubectl apply --validate=false -f or kubectl apply --validate=false -f 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 using it

K8s를 위한 SpringBoot 개발

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

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 Terminal window$ kubectl apply -f database.yamlservice/postgres createdconfigmap/postgres-config createdstatefulset.apps/postgres created Here we deploy our web server as a Kubernetes deployment(web.yaml) to our KIND cluster: Terminal window$ kubectl apply -f we

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 attr

SpringBoot 서비스를 위한 Kubernetes 설정

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

kubectl context

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

minukube 시작하기

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

환경변수 설정

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

spot 인스턴스에서 서버 가용성 개선하기

개요 대덕SW마이스터고 동아리에서 개발한 4개의 교내 서비스(약 250명의 교사와 학생이 사용 중)를 대상으로 서비스 인프라를 통합하는 프로젝트를 진행했다. 이 프로젝트에서 Karpenter를 코드를 커스텀하여, Spot 인스턴스 환경의 Replica 1인 Deployment의 가용성을 96% -99.95%로 개선한 과정을 설명하는 글이다. 문제 상황 해당 인프라에선 각 동아리가 새 프로젝트를 개발할 때마다 배포할 수 있어야 했기 때문에, 자주 변동하는 컨테이너, 컴퓨팅 리소스를 쉽게 관리하기 위해 Kubernetes(EKS)를 사용하였다. 초기에 가용성을 크게 고려하지 않고 각 Deployment의 Replica 수를 1로 유지했음에도, 수십개 컨테이너를 실행하기엔 서버비 예산에 압박이 있었다. 따라서 모