devops

MetalLB에 대한 설명은 생략하고, MetalLB의 로드밸런싱 방식인 Layer2와 BGP 모드에 대해서 정리하려고 한다. 현재 네트워크와 서버 환경에 적합한 모드를 선택하는 것은 안정성과 레이턴시 기준에서 중요하다.두가지 모드의 장단점을 비교해서 어떤 조건에 어떤 모드가 더 적합할지 정리해보자.MetalLB는 두개의 컴포넌트로 구성된다. Controller와 Speaker.Controller는 Deployment로 배포되는 반면에, Speaker는 Daemonset으로 노드마다 하나씩 배포된다.Controller는 서비스의 변화를 모니터링하는 역할을 하는데, 만약 서비스가 Load Balancer 모드로 구성된다면 Controller는 인터넷 프로토콜 주소를 IP 풀로부터 할당되도록 하며 IP의 라..

Calicokubespray로 클러스터를 구성하면 default CNI로 Calico가 셋업된다. 현재 회사에 구성된 클러스터에 사용되는 CNI만큼, 한번 살펴보려고 한다.요즘 Cilium에 대한 언급이 많은데, Cilium은 eBPF 기반으로 L7 네트워크 정책과 보안에 특화되어있어, 고성능 및 세분화된 보안 정책이면 Calico는 Linux 커널의 L3 라우팅 기반으로 BGP(Border Gateway Protocol)을 활용하여 주로 대규모 클러스터 환경에서 기본적인 보안 정책을 지원하며 성능 최적화도 뛰어나다고 알려져있다. Calico는 Tigera라는 회사에서 개발했으며, 아래 공식 문서를 참고하면 좋다.쿠버네티스 워크로드와 레거시 워크로드가 원활하고 안전하게 통신할 수 있게하는 네트워크 솔루션..

Lava NetworkLava Network는 탈중앙화된 RPC 프로바이더 플랫폼이자, 블록체인 데이터 서비스를 위한 마켓플레이스를 구축하고 있다. 이를 통해 Infura, Alchemy, AllThatNode와 같은 기존의 RPC 및 API 인프라 제공자뿐만 아니라, 개인이 직접 운영하는 RPC 노드도 탈중앙화된 네트워크를 통해 클라이언트에게 서비스를 제공할 수 있다.Lava network는 Cosmos SDK 기반으로 구현되었으며, 현재 이더리움, 폴리곤, 솔라나 등 30여 개 이상의 블록체인에 대한 RPC 서비스를 지원한다.Lava Network에는 크게 서비스 사용자(Customer), 서비스 제공자(Provider), 그리고 네트워크의 검증자(Validator)라는 세 가지 주요 주체가 있다. ..

쿠버네티스 컨테이너에서 정의되는 Volume은 컨테이너의 데이터를 영구적으로 저장하거나 컨테이너 간 데이터를 공유하기 위해 사용된다. 각 볼륨은 여러 목적과 특성을 가지고 있어 상황에 맞게 사용된다. 복습 겸, 정리해보자. # Deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: productpage-v1 labels: app: productpage version: v1 spec: replicas: 1 selector: matchLabels: app: productpage version: v1 template: metadata: annotations: prometheus.io/scrape: "true" prometheus.io/port..

Istio? Istio는 오픈소스 서비스 메쉬로, 분리된 어플리케이션을 투명하게 계층화할 수 있다. 현재 쿠버네티스의 네트워크 구성에 가장 많이 사용되고 있는 오픈소스기도 하다. Istio는 쿠버네티스 네트워크의 복잡성을 줄이고, 분산 네트워크 환경에서 여러 어플리케이션들의 연결을 쉽게 설정할 수 있게 지원한다. Istio를 대표하는 3가지의 컨셉은 다음과 같다. Traffic management Sidecar 패턴(Pod 내에 Envoy proxy가 sidecar로 존재)을 이용하여 application 코드의 변경없이 작업자가 VirtualService, DestinationRule이라는 Custom Resource로 손쉽게 원하는 서비스로 트래픽 전송이 가능 k8s로 Canary 배포를 하기 위해선..

Provisioner 프로비저너는 카펜터를 시작할 때 기본적으로 사용되는 노드와 파드의 구성값, 제약 조건을 설정한다. pod의 리밋인 taint를 정의 node의 zone, instance type, computer architecture 정의 node expiration 정의 spec.requirements # Requirements that constrain the parameters of provisioned nodes. # These requirements are combined with pod.spec.affinity.nodeAffinity rules. # Operators { In, NotIn } are supported to enable including or excluding values..

EKS에는 기본적으로 Cluster Autoscaler가 있다. Karpenter가 나오기 전에 유일하게 노드를 확장해주는 방식으로, 여러 프로바이더를 지원한다.그러나 CA는 하나의 자원을 두 주체(ASG, EKS)가 각자의 방식으로 관리하기 때문에 관리 정보에 싱크가 맞지않아 여러 문제가 발생한다. 대표적으로 EKS에서 노드를 삭제해도 인스턴스(노드)가 삭제되지 않는 현상이 있다. 또한, CA의 노드 스케일인 옵션이 적고 느리다. CA의 문제점들 AWS Auto scaling에만 의존하여, 직접적인 노드 삭제와 생성이 안됨 EKS에서 노드 삭제해도 인스턴스가 삭제되지 않음 노드 축소 시, 특정 노드 축소가 어려움 Pulling 방식이기 때문에 API 제한이 걸릴 수 있음 스케일링 속도가 아주 느림 Ka..

ServiceAccount에 적용된 Role의 신뢰관계 설정 문제일 가능성이 크다. ServiceAccount가 AWS 리소스에 접근할 권한이 없기 때문. $ kubectl describe sa aws-load-balancer-controller -n kube-system 먼저 ALB Controller의 SA를 상세 정보를 확인하면, 위와 같이 Annotation에 선언된 Role을 확인할 수 있음. 위에선 AmazonEKSLoadBalancerControllerRole이 SA의 Role로 선언되어 있음. AmazonEKSLoadBalancerControllerRole을 확인해보면 아래와 같은 신뢰관계가 구성되어있다. { "Version": "2012-10-17", "Statement": [ { "Ef..

Ingress 동작 방식 ALB Controller는 API 서버의 Ingress 이벤트를 모니터링한다. 요구 사항을 충족하는 수신 리소스 발견 시, AWS 리소스 생성을 시작한다. 수신 리소스에 맞춰 AWS에서 ALB(ELB v2)를 생성한다.(이 ALB는 인터넷 연결이 되거나 내부에 존재할 수 있으며 Annotation으로 서브넷 지정 가능) Target Group은 수신 리소스에서 지정된 고유 k8s 서비스에 대해 AWS에서 생성된다. 수신 리소스의 Annotation에 설명된 모든 포트에 대해 리스너가 생성된다. 포트는 80과 443이 디폴트며, Annotation에 인증서 첨부도 가능하다. 수신 리소스에 각 경로에 대한 규칙이 생성된다. 특정 경로에 대한 트래픽이 적절한 k9s 서비스로 라우팅된..

kubeconfig 파일을 생성하여 EKS 클러스터 API 서버와 통신할 수 있도록 구성한다. cluster를 컨트롤할 bastion 서버에는 aws cli, kubectl가 미리 설치되어 있어야한다. (혹시 기존에 config 파일이 존재했다면, 삭제하고 재설정하는 것을 권장) kubectl 설치 (아래 aws 공식문서 참고) https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/ # 기존 버전 설치되어 있는 지 확인 $ kubectl version | grep Client | cut -d : -f 5 # kubernetes amd 64 1.23버전 다운 (linux) $ curl -o kubectl https://s3.us-west-2.amazo..