Crossplane을 사용하여, K8S Ingress Controller용 AWS ELB를 생성해보자

Kyu 21.11.05

5,450 7 0

facebook twitter kakao link

7 0

facebook twitter kakao link

배경

팀은 Terraform Operator를 이용하여, TKS Cluster가 사용하는 AWS ELB를 생성/관리 했다.

(참조: https://devocean.sk.com/blog/techBoardDetail.do?ID=163424)

하지만, Terraform Operator의 Reconsile 대상은 실제로 AWS ELB가 아닌 Terraform Cloud의 Workspace임으로, K8S Resource로 실제 관리하고자는 IaaS layer의 Resource를 직접 관리할 수 없었다. 따라서 대안으로 CNCF project인 Crossplane을 검토하기로 한다.

Crossplane overview

[참조] https://crossplane.io/ , https://www.upbound.io/ , https://blog.upbound.io/introducing-crossplane-open-source-multicloud-control-plane/

Crossplane은 upboud에서 만든 K8S controller로 K8S K8S API를 확장하여 Public/Private Cloud의 IaaS/PaaS/SaaS를 Custom Resource로 관리한다. upbound.io에 방문 해 보면, 그들은 Crossplane을 K8S를 확장한 Control plane으로 명명하며, Cloud에서 SaaS형태로 Crossplane을 제공한다. 그들은 SaaS형태의 Crossplane을 Hosted Crossplane이라 부르며, 간략히 설명하면, upbound가 K8S Cluster를 제공하고, 그 제공된 Cluster에 Crossplane operator를 설치해서 제공하는 형태다. kubectl과 kubectl crossplane 을 사용하는 형태다. (제공되는 K8S Cluster는 Crossplane CR외 자원을 사용 못 하게 설정되어 있다)

Crossplane은 CLI tool, Crossplane operator, 각 Provider별 Package로 구성된다. 예를 들어 AWS 사용자는 AWS provider package를 Corssplane이 설치된 K8S Cluster에 설치 후, AWS Access Crendential 정보를 갖는 Config를 생성 후, 해당 Config를 가지고 CR로 AWS Resource를 생성/관리하게 된다.

실습

준비물

AWS 계정에서 Acess key id와 Access key 를 준비해 주세요

Crossplane Operator 설치

kubectl create namespace crossplane-system
 
helm repo add crossplane-stable https://charts.crossplane.io/stable
helm repo update 
helm install crossplane --namespace crossplane-system crossplane-stable/crossplane --version 1.3.0

Crossplane CLI 설치

curl -sL https://raw.githubusercontent.com/crossplane/crossplane/master/install.sh | sh

AWS Provider 설치

AWS 자원에 대한 CR Package를 설치 한다. 2가지 방법이 있다. 첫번째 방법은 crossplane CLI를 사용하는 방법이고, 2번째 방법은 Provider CR를 생성하는 것 이다.

[방안1] Crossplane CLI를 사용한 AWS Provider 설치

https://cloud.upbound.io/browse 를 방문하면, 설치 가능한 Provider를 찾아 볼 수 있고, 설치 명령어를 제공한다. 아래는 AWS Provider 설치 CLI command 다.

kubectl crossplane install provider registry.upbound.io/crossplane/provider-aws:v0.20.0

[방안2] AWS Provider CR 생성

github에 Provider별 Repo가 존재하면, 해당 Repo에 Provider CR 예가 존재한다. (예: https://github.com/crossplane/provider-aws/blob/master/package/crossplane.yaml)

아래는 AWS Provider CR 예로 실제로 동작하는 yaml 이다.

## AWS-Provider.yaml
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: aws-provider
spec:
  package: crossplane/provider-aws:alpha

설치된 Package는 아래와 같이 확인 가능하다.

kubectl get provider.pkg                                                                                                                                      
NAME           INSTALLED   HEALTHY   PACKAGE                         AGE
aws-provider   True        True      crossplane/provider-aws:alpha   16h

Provider Config 설정

Secret 생성: AWS Access ID/Key pair를 저장하는 Secret 생성

echo "aws_access_key_id = 당신의아이디\naws_secret_access_key = 당신의키" > creds.conf
kubectl create secret generic aws-secret-creds -n crossplane-system --from-file=creds=./creds.conf

Provider Config 생성

## provider-config.yaml
apiVersion: aws.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
  name: awsconfig
spec:
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: aws-secret-creds
      key: creds

AWS Security Group 생성

## securitygroup.yaml
apiVersion: ec2.aws.crossplane.io/v1beta1
kind: SecurityGroup
metadata:
  name: ingress-lb
spec:
  deletionPolicy: Delete
  forProvider:
    region: ap-northeast-2
    vpcId: vpc-0590570e043xxxxxx
    groupName: ingress-lb
    description: Security group for LB of Ingress Controller
    egress:
    - ipProtocol: "-1"  #all protocol
      ipRanges:
      - cidrIp: 0.0.0.0/0 #any
    ingress:
    - fromPort: 80
      toPort: 80
      ipProtocol: tcp
      ipRanges:
      - cidrIp: 0.0.0.0/0
    - fromPort: 443
      toPort: 443
      ipProtocol: tcp
      ipRanges:
      - cidrIp: 0.0.0.0/0
    tags:
    - key: creator
      value: crossplane-test
  providerConfigRef:
    name: awsconfig  ## 사용할 provider config

AWS ELB 생성

## elb.yaml
apiVersion: elasticloadbalancing.aws.crossplane.io/v1alpha1
kind: ELB
metadata:
  name: ingress-lb
spec:
  deletionPolicy: Delete
  forProvider:
    region: ap-northeast-2
    securityGroupIdRefs:
      - name: ingress-lb
    subnetIds:   ## Backed EC2 instance로 라우팅 가능한 public subnet
      - subnet-xxxxxxf25d676cdfe
      - subnet-xxxxxxc3c233142eb
      - subnet-xxxxxx4f7b78b628b
    listeners:
      - instancePort: xxx80
        instanceProtocol: tcp
        loadBalancerPort: 80
        protocol: tcp
      - instancePort: yy443
        instanceProtocol: tcp
        loadBalancerPort: 443
        protocol: tcp
    healthCheck:
      target: HTTP:zzzz/healthz   ## path 지정시 HTTP 명시 필요
      timeout: 5
      interval: 30
      unhealthyThreshold: 6  #버그인듯 함. 어떤 값을 설정해도 healthyThreshold랑 동일하게 적용됨
      healthyThreshold: 3
    tags:
      - key: creator
        value: crossplane-test
  providerConfigRef:
    name: awsconfig

ELB Attachments 생성

## elbattachment.yaml
apiVersion: elasticloadbalancing.aws.crossplane.io/v1alpha1
kind: ELBAttachment
metadata:
  name: instance-1
spec:
  deletionPolicy: Delete
  forProvider:
    region: ap-northeast-2
    elbNameRef:
      name: ingress-lb
    instanceId: i-xxxxxxc841693006d
  providerConfigRef:
    name: awsconfig
-----
apiVersion: elasticloadbalancing.aws.crossplane.io/v1alpha1
kind: ELBAttachment
metadata:
  name: instance-2
spec:
  deletionPolicy: Delete
  forProvider:
    region: ap-northeast-2
    elbNameRef:
      name: ingress-lb
    instanceId: i-xxxxxxbaadd115d52
  providerConfigRef:
    name: awsconfig
-----
apiVersion: elasticloadbalancing.aws.crossplane.io/v1alpha1
kind: ELBAttachment
metadata:
  name: instance-3
spec:
  deletionPolicy: Delete
  forProvider:
    region: ap-northeast-2
    elbNameRef:
      name: ingress-lb
    instanceId: i-xxxxxx89c0de0f8d8
  providerConfigRef:
    name: awsconfig

Discovery

Corssplane을 사용해서, 만들어진 CR를 K8S API를 통해 조회해 볼 수 있기 때문에, 직접 관리 가능했다.

## security group
kubectl get securitygroup
NAME         READY   SYNCED   ID                     VPC                     AGE
ingress-lb   True    True     sg-034ff105928690059   vpc-xxxxxx0e043abe9a7   36m

## ELB
kubectl get elb                                                                                                                              
NAME         ELBNAME      DNSNAME                                                  VPCID                   READY   SYNCED   AGE
ingress-lb   ingress-lb   ingress-lb-xxxxxx2166.ap-northeast-2.elb.amazonaws.com   vpc-xxxxxx0e043abe9a7   True    True     14m

## ELB Attachments
kubectl get elbattachment                                                                                                                         
NAME         ELBNAME      INSTANCEID            READY   SYNCED   AGE
instance-1   ingress-lb   i-xxxxxxc841693006d   True    True     11m
instance-2   ingress-lb   i-xxxxxxbaadd115d52   True    True     11m
instance-3   ingress-lb   i-xxxxxx89c0de0f8d8   True    True     11m

Terraform operator와 비교하면, yaml 형태로 IaaS spec을 작성하기 때문에, 가독성/개발편의가 더 좋았다. 또한 중간에 한 단계가 빠지기 때문에(Terraform Cloud의 Job queue에의한 대기 시간) 좀더 빠르게 동작한다.

Operator 동작에 대해서는 다음과 같이 정리 할 수 있었다.

	Reconsile 대상	CR변경시	IaaS Resource 수동 변경시
Terraform Operator	Terraform Cloud Workspace	IaaS Resource 변경됨	IaaS Resource 변경 됨
Crossplane	IaaS Resource	IaaS Resource 변경됨	Crossplane Operator가 CR과 동일 상태로 원복시킴

Terraform Operator에 비해 Crossplane이 보다 K8S의 선언적 관리 Framework을 착실하게 지원하고 있다.

Terraform Operator는 기존의 Terraform CLI tool의 Legacy위에 Operator concept을 더한 느낌이라면, Crossplane의 경우 K8S Natvie Solution 으로 판단된다. 다만 Crossplane의 경우 AWS를 제외한 다른 CSP의 경우 지원되는 IaaS Resource가 적은 단점이 존재한다. 아마도 후발주자이기 때문인 듯 하다.

앞으로의 행보가 기대된다.

#Kubernetes #Open Infra #Amazon Web Service #DevOps

등록

DEVOTEE를 활성화 시키면
지금 작성한 댓글에 AI가 댓글을 달아줍니다.

익명

Kyu 님의 최신 블로그

[K8S 보안] DevSecOps

서론 Kubernetes 보안 연재를 마무리를 어떤 주제로 마무리해야 하나 고민 했다. 사실 필자는 Policy란 조금은 모호한 주제를 선택했고 앞으로 기술할 내용도 Policy에 대한 것 이다. 하지만 Policy는 너무 광의에 뜻 이지 않은가? 이글을 쓰는 의도를 좀더 분명하게 전달 할 수 있는 제목이 필요했다. 고민 끝에 크게 내키지는 않지만 DevSecOps란 Keyword를 사용하기로 했다. (사실 필자는 세상의 Buzz word를 극도로 싫어한다. 물론 Cooking을 위해서 필요한 일인 건 맞지만 코에 걸면 코걸이 귀에 걸면 귀걸이로 변질 되면서, 수많은 숙제만 양산하기에 때문이다.) 여하튼, 마지막 주제는 DevSecOps다. 땅땅땅 IT의 몰락과 ...
[K8S 보안 3탄] Container 보안

서론 Kubernetes는 다수의 Computer에 container를 Best Practice 를 기반한 구조로 배포하고 관리하는 PaaS 다. 여기서 주목할 점은 Kubernetes는 가상화 플랫폼인 IaaS가 아니라는 점 이다. IaaS는 OS 가상화를 통해서 배포되는 서비스간 종속성 문제를 해결하고 더불어서 서비스간 Computing 환경을 분리하여 강한 보안성을 제공한다. 즉 동일 Computer에서 동작하는 서로다른 VM에서 구동되는 서비스들은 서로를 볼 수 없고, OS level에서는 그 어떤 자원도 공유하지 않기 때문에 보안에 취약한 서비스를 통해 다른 서비스에 접근이 어렵다. 하지만 Container는 가상화가 아니며, 기본적으로 Host OS에 ...
[K8S 보안 2탄] K8S 사용자 관리

시작 : Discovery Kubernetes를 설치하면, kubeconfig 라는 Kubernetes 접근에 대한 설정이 Home Directory 및 .kube라는 Directory 및에 config란 이름으로 저장되어 있는 것을 발견 할 수 있습니다. kubeadm 으로 Kubernetes를 설치한 후 아래와 같은 메시지를 확인하실 수 있습니다. Your Kubernetes control-plane has initialized successfully! To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/ku...
[K8S 보안 1탄] K8S 시스템 보안

서론 K8S 장점이나, 기본적인 구조에 대해서 논의하는 것은 마치 이효리님의 스타성을 논하는 것 만큼 아무 의미 없는 것이 되었다. 따라서, 2024년에는 좀더 Deep 한 주제에 대해서 논의하고 한다. 필자는 그 첫번째 이슈로 보안을 다루어 보기로 했다. K8S는 백화점, 고속버스 터미널 같은 Platform으로, 공통 편의 시설을 제공하여 효율을 높이는 것이 본질이다. 따라서 필연적으로 공유하는 그 무엇인가가 발생하기 때문에, 보안은 매우 중요한 화두라 생각한다. 보안에 대한 첫번째 기고는 K8S 시스템 보안에 대해서 논하고자 한다. 결론 부터 말하자면, Kubeadm을 사용하면 큰 문제 없이 모든것이 해결된다. (얼마나 기쁜일 인가?) 하지만, 기술을 하는 ...

목록으로

DEVOCEAN

로그인 선택

미리보기

커뮤니티

글 등록

임시저장함

데보션 블로그 게재 요청