짧은 생각 모음집 - crossplane, eBPF 편

crossplane, 이거 재밌는 아이디어 같다.

crossplane은, 간단히 말하면 클라우드 리소스를 kuberenetes CRD로 정의해서 관리할 수 있도록 하는 프레임워크인데, Terraform을 yaml로 관리한다고 생각하면 쉽다.

https://www.crossplane.io/

Crossplane - The cloud-native control plane framework

예를 들어, s3 버킷을 관리한다고 하자.

apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
metadata:
  name: aws-config
annotations:
  eks.amazonaws.com/role-arn: arn:aws:iam::894897474192:role/crossplane-role
  spec:
    podSecurityContext:
    fsGroup: 2000

apiVersion: s3.aws.crossplane.io/v1beta1
kind: Bucket
metadata:
  name: knoldus-crossplane-bucket
  namespace: crossplane-system
spec:
  forProvider:
    acl: private
    locationConstraint: us-east-1
    versioningConfiguration:
      status: Enabled
      providerConfigRef:
        name: default

요런 식으로 매니페스트 파일을 생성해 kubectl appply 하면 생성된다. 와!

선언형 구성이다보니 이런저런 장점도 생기는데,

 

1. 의도하지 않은 변경과 제거를 막을 수 있다.

k8s의 큰 특징 중 하나인, 의도한 상태로 돌아가도록 최선을 다함. 의 영향을 당연히 받게 되어 앞서 생성한 버킷을 누군가 AWS 콘솔에서 삭제해도 k8s가 (정확히 말하자면 crossplane provider가) 복구시킨다.

아이러니한 건 의도치 않은 변경과 제거를 막을 수 있다는 말은 곧 의도치 않은 변경과 복구를 불러올 수 있다는 것… (disaster)

안정성에 대해 더욱 검증해야 한다.

 

2. Terraform에 익숙치 않은 사용자에게 도움이 된다.

HCL로 정의되는 Terraform 특성상, 진입장벽이 존재하는데 그에 비해 yaml로 정의되는 crossplane은 더 도움이 될 수도 있다.

하지만, HCL 문법을 적극적으로 사용하지 않다면 큰 장점은 아닌 게.

Terraform을 작성하는 것이 어려운 것이 아니라, AWS 리소스의 자잘 자잘한 특성 값을 모두 알아야 하는 것이 어려운 것이기 때문이다.

어차피 crossplane을 쓰더라도 저 구석구석 세부적인 필드값 다 알아야 한다.

 

3.Atlantis를 대체할 수 있다.

atlantis도 좋은 도구이긴 한데, 플랜 돌리고 하는 게 시간도 많이 걸리고 누가 쓰고 있으면 lock도 풀어야 하고,,, 하는데.

요 crossplane + GitOps(ArgoCD, Flux) 방식을 채택하면 atlantis를 대체할 수 있다.

그럼 terraform plan처럼 미리 보기는 어떻게 하냐고?

ArgoCD를 사용하니까 거기서 diff를 확인하면 된다.

그런데 diff만 확인해서는 인프라에 적용될 세세한 변경사항을 확인하지 못할 텐데.. 흠. 아직 써보지는 못해 모르겠다.

 

결론은 재밌는 아이디어지만 커뮤니티 driven 프로젝트임에도 스타 수가 현재는 낮고(7천 쯤) 클라우드 벤더사들의 provider 업데이트가 꾸준히 이뤄져야 하는점이 걸린다. 물론 요 커뮤니티에도 그 점을 아주 잘 알고 있어서 terraform에 있는 클라우드 provider를 crossplane으로 가져오려는 시도를 꾸준히 하고 있다.

 

---

eBPF가 과연 좋을까?

요즘 여기저기서 eBPF가 뜨고 있다. 최근 즐겨 듣는 팟캐스트인 "DevOps Paradox" 채널에서 "Learning eBPF with Liz Rice" 주제로 에피소드가 올라왔기도 해서.. (참고로 저 Liz Rice라는 분이 오렐리에서 "Learning ePBF" 책을 내신 분이다. )

 eBPF에 대해서는 아래 링크를 참고해서 이해하도록 노력하면 좋다. (내용이 좀 어렵다...)

https://ebpf.io/what-is-ebpf/

What is eBPF? An Introduction and Deep Dive into the eBPF Technology

간단하게 말해서 리눅스 커널 내에서 실행되는 프로그램을 작성하는 프레임워크다. 핵심 기능은 다음 3가지로 요약된다.

• 네트워크 패킷 필터링: eBPF를 사용하여 네트워크 패킷을 필터링하고, 특정 조건에 따라 패킷을 처리할 수 있습니다. 이를 통해 네트워크 보안 및 모니터링 기능을 강화할 수 있습니다.
• 시스템 트레이싱: eBPF를 사용하여 시스템의 다양한 이벤트를 추적하고 분석할 수 있습니다. 이를 통해 시스템의 성능 문제나 버그를 식별하고, 디버깅 및 모니터링에 활용할 수 있습니다.
• 보안 강화: eBPF를 사용하여 시스템의 보안을 강화할 수 있습니다. 예를 들어, 악성 코드나 취약점을 탐지하고 차단하는 기능을 구현할 수 있습니다.

현재 Service Mesh에 대해 떠오르는 건 Istio + Envoy 조합으로 사이드카 방식의 아키텍처인데. 기본적으로 사이드카가 착한 기생충(?) 마냥 CPU랑 메모리를 먹으면서 붙어 있기 때문에 추가적인 리소스가 소모된다. 운영 비용이나 유지, 보수 관리 비용도 만만치 않다.

eBPF는 요런 아이디어에서 출발한다.
"k8s 환경에서 각 노드들은 커널이 하나씩만 있고. 그 노드에서 실행되는 모든 컨테이너는 동일한 커널을 공유하니까, 요걸 활용하면 사이드카 프락시를 노드로 쫙 통합할 수 있지 않을까?"

그래서 사이드카 없이 애플리케이션을 감지할 수 있게 Cilium 같은 서비스 메시를 사용해 "Sidecarless" 모델을 사용할 수 있다. 

더 파고들면 너무 길어질 것 같아서... 나중에 한번 따로 정리해 봐야겠다.

아무튼 더 낮은 하드웨어 비용, 운영 비용과 줄어드는 latency를 강점으로 내세우고 있는데, 막상 생각해 보면 요런 생각이 든다.

극단적으로 k8s환경에서 service mesh를 sidecar 패턴에서 sidecarless 패턴으로 교체했을 때,

불필요한 홉을 줄여 latency를 줄일 수 있다 는 장점도 있고 파드마다 붙어있는 sidecar들이 리소스를 잡아먹고 있는 것도 해결할 수도 있고, Service mesh의 복잡성을 줄일 수 있다는 장점들이 있지만

eBPF를 사용해서 커널단에서 해결한다면 여러 신규기능의 배포에 있어서 많은 문제가 있을 것 같다는 생각도 든다.

 

생각해보면 각 서비스가 충돌할 때면 서비스에 종속된 다른 모든 시스템이 중단된다는 것이 문제여서 이러한 의존성을 없애기 위해 도커와 쿠버네티스를 개발해 적용했는데 (느슨한 결합),

 

강력한 기능을 수행할 수 있는 이 벌들(eBPF)을.. 단일 지점인 커널에 투입시킨다면 결국 이 벌들이 고장 나면 모든 시스템이 중단될 텐데,이 지점에서 과연 Docker&K8s를 사용하는 의미가 있을지에 대한 근본적인 의문이 든다.

k8s에서 Pod에 사이드카 컨테이너가 있을 때 사이드카 충돌이 일어나면 그 Pod만 없어지고 그것 하나만 다시 시작되고, 다른 Pod는 영향을 받지 않게 되는데. 어쨌든 이러한 고립과 격리가 쿠버네티스의 핵심 가치라고 생각하기 때문이다...

또 eBPF 프로그램은 태생적으로 매우 보수적이고 제한적이게 개발되어야 한다. 단순하게 생각해도 커널에서 코드를 실행하는 것은 정말 위험하기 때문이다..! 괜히 system call이 존재하는 게 아니다.

신뢰하지 않는 행위를 방지하기 위해 커널은 eBPF 코드에 상당한 제한사항을 가해야만 한다. eBPF 프로그램은 실행이 허용되기 전에 “verifier”라고 하는 도구로 프로그램에 대해 엄격한 정적 분석 검사를 수행하는데,

분명한 건 요 verifier가 현재로서는 완전해 보이지 않다는 것.. 이 때문에 eBPF 프로그램은 매우 제한적이게 개발될 것 같다. 아마 루프도 제한이 있을 것이고 지정된 limits을 초과할 수도 없게 될 것이니..

심지어 디버깅은 어떻게 할 것인지.. 재현할 수 없는 매우 어려운 deep단의 버그가 있다면 생각만 해도 끔찍한 일이다. 해저 탐험하듯이 7 layer에서 커널단까지 파고들어 가 디버깅해야 한다 ㅋㅋㅋ

분명 장점에 운영 코스트를 줄여준다고 했는데, 왜 내가 보기에는 운영 코스트는 더 늘어날 것 만 같은지..?

그럼에도 아마 극단적으로 latency를 줄여야 하는 코인 거래소 인프라나 게임 쪽 인프라에는 PoC를 진행할만할 것 같기도 하다.

 

---

적다 보니 글이 너무 길어졌다.. 분명 짧은 생각 모음집이었는데ㅠ

karpenter나 github actions에 관해서도 적으려 했는데, 시간 나면 적어야지.