Kubernetes에서 IP 주소 화이트리스트: 우리가 배운 것

Linode 시스템 엔지니어 Jon "jfred" Frederickson이 Linode에서 Kubernetes를 실행하기 위한 IP 화이트리스트 기능을 구축한 경험을 공유합니다.

Linode의 엔지니어링 팀이 Kubernetes 기능을 구축함에 따라 예상대로 많은 장애물에 부딪혔습니다. 그러나 우리가 예상하지 못한 한 가지 문제가 발생했습니다. 이미 보유한 인프라에서 Kubernetes에서 실행되는 애플리케이션을 허용 목록에 추가하는 방법입니다.

여기 Linode에서는 여러 내부 애플리케이션을 실행합니다. 방화벽 규칙을 사용하면 이러한 앱은 필요한 네트워크 및 시스템에서만 액세스 할 수 있습니다.

자체 데이터베이스가 있는 응용 프로그램이있는 경우 해당 데이터베이스는 해당 응용 프로그램의 인스턴스만 연결할 수 있어야 합니다. 둘 다 Kubernetes 클러스터에서 실행되고 있다면 간단합니다. NetworkPolicies를 사용하면 이를 잠글 수 있습니다. 반면에 하나의 서비스가 클러스터 외부에서 실행 중이면 상황이 더 복잡해지기 시작합니다.

이미 IP 화이트리스트에 대한 기존 자동화가 있었지만 Kubernetes 클러스터는 지금까지 인프라의 다른 어떤 것보다 더 동적 일 가능성이 있습니다. 이것이 클러스터에 노드가 추가 및 제거 될 때 화이트리스트를 최신 상태로 유지해야 하는 이유입니다. Kubernetes를 기존 인프라에 도입하는 모든 사람에게 이 문제가 상당히 일반적인 문제라고 생각했지만 문제에 대한 다른 공개 솔루션을 찾지 못했습니다.

문제

내 문제는 클러스터 외부 서버의 특정 클러스터에 있는 모든 노드를 화이트리스트에 추가하려는 경우 이상적인 구성이 어떻게 생겼냐는 것입니다.

Kubernetes 인식 도구가 없으면 클러스터 노드의 개별 IP 주소를 하나씩 수동으로 화이트리스트에 추가해야 했습니다. 이는 시간 소모적일 뿐만 아니라 개발 프로세스의 주요 장애물인 인적 오류의 가능성이 더 커집니다.

해결책

다음 몇 주 동안 저는 (대부분) Kubernetes 클러스터를 단일 IP를 수동으로 허용하는 것처럼 간단하게 허용하는 솔루션을 구축했습니다.

우리는 Salt를 사용하여 인프라를 관리하고 이미 Salt 공식을 사용하여 방화벽 규칙을 관리했습니다. Salt에 등록된 인프라 중에는 이미 화이트리스트를 작성할 때 특정 클래스의 시스템을 찾을 수 있는 메커니즘이 있었기 때문에 Kubernetes 클러스터와 유사한 것을 찾고 있었습니다.

Salt는 매우 유연하며 사용자 정의 모듈을 쉽게 작성할 수 있습니다. 예를 들어, iptables 공식은 하나를 사용하여 Salt의 노드 별 구성 ("기둥" 데이터)에서 iptables 규칙을 생성합니다. 필라에 저장된 규칙 목록에서 한 번에 하나의 규칙을 작성하여 이를 수행합니다. 그것은 많은 문자열 연결이며, 약간 못생겼습니다. 운 좋게도 iptables 규칙 형식은 충분히 안정적이므로 잘 작동합니다. 다음은 그 모습의 맛보기입니다:

Kubernetes의 유연한 API 덕분에 이 통합은 개념적으로 어렵지 않았습니다. 기본적으로 K8s 클러스터에 대한 새로운 규칙 유형을 추가했습니다. 수식이 해당 유형의 규칙을 만나면 해당 클러스터에 도달하여 노드의 IP를 가져와서 로컬로 캐시하고 각 IP에 대한 iptables 규칙을 삽입합니다. 캐싱은 간헐적인 네트워크 오류로 인해 문제가 발생하지 않도록 하는 것입니다. 다음과 같이 사용하면 됩니다.

향후 계획은 무엇입니까?

궁극적으로 저는 Linode 커뮤니티의 도움을 받아 도구의 역량을 더욱 발전시키기 위해 전체 포뮬러를 공개하고 싶습니다.

하지만 다음 단계는 새 노드가 클러스터에 합류하고 탈퇴할 때 이러한 규칙이 자동으로 업데이트되도록 하는 것입니다. 목표는 클러스터를 지속적으로 화이트리스트에 추가하는 것이 단일 IP를 화이트리스트에 올리는 것만큼 간단하게 하는 것이지만 아직 그 정도는 아닙니다.

공식은 방화벽 구성이 적용될 때만 새 노드를 선택하지만, 자동은 아닙니다. 방화벽 구성을 주기적으로 다시 적용하여 이 문제를 해결할 수 있기 때문에 이것은 큰 문제가 아닙니다.

그러나 나는 그것을 더 반응적으로 만드는 방법을 찾고 싶습니다. 내가 구 한 메커니즘은 해당 이벤트 (Kubernetes에서 새 노드 객체 생성)를 수신하고 업데이트를 시작하게 합니다 (아마도 Salt 이벤트 버스를 통해서 말입니다). 이상적으로는 Kubernetes 방화벽 규칙을 구성하는 것 외에 수동 단계가 필요하지 않습니다. 우리가 공식을 공개하면 당신이 그것을 알아내는 데 도움이 될 수 있습니다!

지금은 우리가 만든 것에 정말 만족하며 Kubernetes를 실험하는 Linode 사용자에게 자산이 될 것이라고 믿습니다.

Linode의 시스템 엔지니어링 프로세스에 대해 알아주셔서 감사합니다. 우리가 한 일에 대해 궁금한 점이 있으면 의견란에 알려주십시오.

Linode의 Kubernetes에 관심이 있으십니까?

우리 팀은 컨테이너화된 애플리케이션과 워크로드를 배포하고 관리하기 위한 완전 관리형 컨테이너 조정 엔진인 Linode Kubernetes Engine (LKE)의 베타 버전을 소개하게 된 것을 자랑스럽게 생각합니다.

그래도 피드백이 필요합니다. 여기에서 LKE 베타에 등록하여 사용해보고 무료 Linode 상품을 받으세요.