Kubernetes 네트워킹을 위한 Calico: 소개 및 약간의 경험

이 기사의 목적은 독자에게 Kubernetes의 네트워킹 및 네트워크 정책 관리의 기본 사항과 표준 기능을 확장하는 타사 Calico 플러그인을 소개하는 것입니다. 그 과정에서 우리의 운영 경험에서 얻은 실제 사례를 사용하여 구성의 용이성과 일부 기능을 시연할 것입니다.

Kubernetes 네트워킹 어플라이언스에 대한 빠른 소개

Kubernetes 클러스터는 네트워크 없이는 상상할 수 없습니다. 우리는 이미 기본 사항에 대한 자료를 출판했습니다. “Kubernetes의 네트워킹에 대한 그림 가이드"그리고"보안 전문가를 위한 Kubernetes 네트워크 정책 소개".

이 기사의 맥락에서 K8s 자체는 컨테이너와 노드 간의 네트워크 연결을 담당하지 않는다는 점에 유의하는 것이 중요합니다. CNI 플러그인 (컨테이너 네트워킹 인터페이스). 이 개념에 대해 더 자세히 알아보려면 그들도 나한테 말했지.

예를 들어, 이러한 플러그인 중 가장 일반적인 것은 플란넬 — 각 노드에 브리지를 올리고 여기에 서브넷을 할당하여 모든 클러스터 노드 간에 완전한 네트워크 연결을 제공합니다. 그러나 완전하고 규제되지 않은 접근성이 항상 유익한 것은 아닙니다. 클러스터에서 최소한의 격리를 제공하려면 방화벽 구성에 개입해야 합니다. 일반적으로 이는 동일한 CNI의 통제하에 놓이기 때문에 iptables에 대한 제XNUMX자의 개입이 잘못 해석되거나 완전히 무시될 수 있습니다.

그리고 Kubernetes 클러스터에서 네트워크 정책 관리를 구성하기 위한 "즉시 사용 가능한" 기능이 제공됩니다. 네트워크정책 API. Этот ресурс, распространяющийся на выбранные пространства имён, может содержать правила для разграничения доступа от одних приложений к другим. Он также позволяет настраивать доступность между конкретными pod’ами, окружениями (пространствами имён) или блоками IP-адресов:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

이것은 가장 원시적인 예가 아니다. 공식 문서 네트워크 정책이 작동하는 방식의 논리를 이해하려는 욕구가 완전히 좌절될 수 있습니다. 하지만 우리는 여전히 네트워크 정책을 이용하여 트래픽 흐름을 처리하는 기본 원리와 방법을 이해하려고 노력할 것입니다...

트래픽에는 Pod에 들어가는(Ingress) 것과 Pod에서 나가는(Egress)의 두 가지 유형이 있다는 것이 논리적입니다.

실제로 정치는 움직이는 방향에 따라 이 두 가지로 나누어진다.

다음 필수 속성은 선택자입니다. 규칙이 적용되는 사람. 이는 포드(또는 포드 그룹) 또는 환경(예: 네임스페이스)일 수 있습니다. 중요한 세부 사항: 이러한 개체의 두 유형 모두 레이블(상표 Kubernetes 용어로) - 정치인들이 함께 운영하는 것입니다.

일종의 레이블로 통합된 한정된 수의 선택기 외에도 "모든 항목/모두 허용/거부"와 같은 규칙을 다양한 변형으로 작성하는 것이 가능합니다. 이를 위해 다음 형식의 구성이 사용됩니다.

  podSelector: {}
  ingress: []
  policyTypes:
  - Ingress

— 이 예에서는 환경의 모든 포드가 수신 트래픽에서 차단됩니다. 다음 구성을 사용하면 반대 동작을 얻을 수 있습니다.

  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

나가는 경우도 마찬가지입니다.

  podSelector: {}
  policyTypes:
  - Egress

- 끄려고요. 그리고 포함할 내용은 다음과 같습니다.

  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

클러스터용 CNI 플러그인 선택으로 돌아가서 다음 사항에 주목할 가치가 있습니다. 모든 네트워크 플러그인이 NetworkPolicy를 지원하는 것은 아닙니다.. 예를 들어, 이미 언급한 Flannel은 네트워크 정책을 구성하는 방법을 모릅니다. 직접적으로 말한거야 공식 저장소에 있습니다. 대안도 언급되어 있습니다 - 오픈 소스 프로젝트 옥양목이는 네트워크 정책 측면에서 Kubernetes API의 표준 세트를 크게 확장합니다.

Calico 알아보기 : 이론

Calico 플러그인은 Flannel(하위 프로젝트)과 통합하여 사용할 수 있습니다. 운하) 또는 독립적으로 네트워크 연결 및 가용성 관리 기능을 모두 포함합니다.

K8s "박스형" 솔루션과 Calico의 API 세트를 사용하면 어떤 기회가 제공됩니까?

NetworkPolicy에 내장된 내용은 다음과 같습니다.

• 정치인은 환경에 의해 제한됩니다.
• 정책은 라벨이 표시된 포드에 적용됩니다.
• 규칙은 포드, 환경 또는 서브넷에 적용될 수 있습니다.
• 규칙에는 프로토콜, 명명된 또는 기호화된 포트 사양이 포함될 수 있습니다.

Calico가 이러한 기능을 확장하는 방법은 다음과 같습니다.

• 정책은 포드, 컨테이너, 가상 머신 또는 인터페이스 등 모든 개체에 적용될 수 있습니다.
• 규칙에는 특정 작업(금지, 허가, 기록)이 포함될 수 있습니다.
• 규칙의 대상 또는 소스는 포트, 포트 범위, 프로토콜, HTTP 또는 ICMP 특성, IP 또는 서브넷(4세대 또는 6세대), 선택기(노드, 호스트, 환경)일 수 있습니다.
• 또한 DNAT 설정 및 트래픽 전달 정책을 사용하여 트래픽 통과를 규제할 수 있습니다.

Calico 저장소의 GitHub에 대한 첫 번째 커밋은 2016년 XNUMX월로 거슬러 올라가며, XNUMX년 후 프로젝트는 Kubernetes 네트워크 연결 구성에서 선도적인 위치를 차지했습니다. 이는 예를 들어 설문 조사 결과로 입증됩니다. 뉴 스택(The New Stack)이 지휘한:

다음과 같은 K8을 사용하는 많은 대규모 관리형 솔루션 아마존 EKS, Azure AKS, 구글 GKE 다른 사람들은 그것을 사용하도록 권장하기 시작했습니다.

성능은 여기에서 모든 것이 훌륭합니다. 제품 테스트에서 Calico 개발 팀은 초당 50000개의 컨테이너 생성 속도로 500개의 물리적 노드에서 20개 이상의 컨테이너를 실행하여 천문학적인 성능을 보여주었습니다. 스케일링에는 아무런 문제가 확인되지 않았습니다. 그러한 결과 발표됐다 이미 첫 번째 버전이 발표되었습니다. 처리량 및 리소스 소비에 초점을 맞춘 독립적인 연구에서도 Calico의 성능이 Flannel의 성능과 거의 비슷하다는 사실이 확인되었습니다. 예를 들면:

이 프로젝트는 매우 빠르게 개발되고 있으며 K8s, OpenShift, OpenStack 관리되는 인기 솔루션에서의 작업을 지원하며 다음을 사용하여 클러스터를 배포할 때 Calico를 사용할 수 있습니다. 콥, Service Mesh 네트워크 구축에 대한 언급이 있습니다(여기에 예가 있습니다 Istio와 함께 사용됨).

칼리코로 연습하기

바닐라 쿠버네티스를 사용하는 일반적인 경우 CNI를 설치하면 파일을 사용하게 됩니다. calico.yaml, 공식 홈페이지에서 다운로드, 사용하여 kubectl apply -f.

일반적으로 플러그인의 현재 버전은 Kubernetes의 최신 2~3개 버전과 호환됩니다. 이전 버전에서의 작동은 테스트되지 않으며 보장되지 않습니다. 개발자에 따르면 Calico는 iptables 또는 IPVS 위에 CentOS 3.10, Ubuntu 7 또는 Debian 16을 실행하는 8 이상의 Linux 커널에서 실행됩니다.

환경 내 격리

일반적인 이해를 위해 Calico 표기법의 네트워크 정책이 표준 표기법과 어떻게 다른지, 규칙 생성 접근 방식이 어떻게 가독성과 구성 유연성을 단순화하는지 이해하기 위한 간단한 사례를 살펴보겠습니다.

클러스터에는 Node.js와 PHP라는 2개의 웹 애플리케이션이 배포되어 있으며 그 중 하나는 Redis를 사용합니다. Node.js와의 연결을 유지하면서 PHP에서 Redis에 대한 액세스를 차단하려면 다음 정책을 적용하면 됩니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-redis-nodejs
spec:
  podSelector:
    matchLabels:
      service: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: nodejs
    ports:
    - protocol: TCP
      port: 6379

기본적으로 우리는 Node.js에서 Redis 포트로 들어오는 트래픽을 허용했습니다. 그리고 그들은 분명히 다른 어떤 것도 금지하지 않았습니다. NetworkPolicy가 나타나면 별도로 지정하지 않는 한 여기에 언급된 모든 선택기가 격리되기 시작합니다. 그러나 선택기에서 다루지 않는 다른 개체에는 격리 규칙이 적용되지 않습니다.

예제에서는 apiVersion Kubernetes는 즉시 사용 가능하지만 사용을 방해하는 것은 없습니다. Calico 전달과 동일한 이름의 리소스. 구문이 더 자세하므로 위 사례에 대한 규칙을 다음 형식으로 다시 작성해야 합니다.

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-nodejs
spec:
  selector: service == 'redis'
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: service == 'nodejs'
    destination:
      ports:
      - 6379

위에서 언급한 일반 NetworkPolicy API를 통한 모든 트래픽을 허용하거나 거부하기 위한 구성에는 이해하고 기억하기 어려운 괄호가 포함된 구성이 포함되어 있습니다. Calico의 경우 방화벽 규칙의 논리를 반대로 변경하려면 다음과 같이 변경하면 됩니다. action: Allow 에 action: Deny.

환경별 격리

이제 애플리케이션이 Prometheus에서 수집하고 Grafana를 사용하여 추가 분석을 위한 비즈니스 측정항목을 생성하는 상황을 상상해 보세요. 업로드에는 기본적으로 공개적으로 다시 볼 수 있는 민감한 데이터가 포함될 수 있습니다. 이 데이터를 엿보는 눈으로부터 숨기자:

Prometheus는 일반적으로 별도의 서비스 환경에 배치됩니다. 예에서는 다음과 같은 네임스페이스가 됩니다.

apiVersion: v1
kind: Namespace
metadata:
  labels:
    module: prometheus
  name: kube-prometheus

분야 metadata.labels 이것은 우연이 아닌 것으로 판명되었습니다. 상술 한 바와 같이, namespaceSelector (게다가 podSelector) 레이블과 함께 작동합니다. 따라서 특정 포트의 모든 Pod에서 메트릭을 가져오려면 일종의 레이블을 추가하거나 기존 레이블에서 가져와야 하며 다음과 같은 구성을 적용해야 합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          module: prometheus
    ports:
    - protocol: TCP
      port: 9100

Calico 정책을 사용하는 경우 구문은 다음과 같습니다.

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  ingress:
  - action: Allow
    protocol: TCP
    source:
      namespaceSelector: module == 'prometheus'
    destination:
      ports:
      - 9100

일반적으로 특정 요구 사항에 맞게 이러한 종류의 정책을 추가하면 클러스터의 애플리케이션 작동에 대한 악의적이거나 우발적인 간섭으로부터 보호할 수 있습니다.

Calico의 제작자에 따르면 모범 사례는 "모든 것을 차단하고 필요한 것을 명시적으로 여는" 접근 방식입니다. 공식 문서 (다른 사람들도 비슷한 접근 방식을 따릅니다. 특히 이미 언급된 기사).

추가 Calico 객체 사용

확장된 Calico API 세트를 통해 포드에 국한되지 않고 노드의 가용성을 규제할 수 있다는 점을 상기시켜 드리겠습니다. 다음 예제에서는 GlobalNetworkPolicy 클러스터에서 ICMP 요청을 전달하는 기능이 닫힙니다(예: 포드에서 노드로, 포드 간 또는 노드에서 IP 포드로 ping).

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: block-icmp
spec:
  order: 200
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
    protocol: ICMP
  egress:
  - action: Deny
    protocol: ICMP

위의 경우에도 클러스터 노드가 ICMP를 통해 서로 “접근”할 수 있습니다. 그리고 이 문제는 다음과 같은 방법으로 해결됩니다. GlobalNetworkPolicy, 엔터티에 적용됨 HostEndpoint:

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: deny-icmp-kube-02
spec:
  selector: "role == 'k8s-node'"
  order: 0
  ingress:
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow
    protocol: ICMP
---
apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: kube-02-eth0
  labels:
    role: k8s-node
spec:
  interfaceName: eth0
  node: kube-02
  expectedIPs: ["192.168.2.2"]

VPN 사례

마지막으로, 표준 정책 세트로는 충분하지 않은 클러스터 근처 상호 작용의 경우 Calico 기능을 사용하는 매우 실제적인 예를 제시하겠습니다. 웹 애플리케이션에 액세스하기 위해 클라이언트는 VPN 터널을 사용하며, 이 액세스는 엄격하게 제어되며 사용이 허용된 특정 서비스 목록으로 제한됩니다.

클라이언트는 표준 UDP 포트 1194를 통해 VPN에 연결하고, 연결되면 포드 및 서비스의 클러스터 서브넷에 대한 경로를 수신합니다. 다시 시작 및 주소 변경 중에 서비스가 손실되지 않도록 전체 서브넷이 푸시됩니다.

구성의 포트는 표준이므로 애플리케이션을 구성하고 이를 Kubernetes 클러스터로 전송하는 프로세스에 약간의 차이가 있습니다. 예를 들어, UDP용 AWS LoadBalancer는 작년 말 말 그대로 제한된 지역 목록에 나타났으며 NodePort는 모든 클러스터 노드에서의 전달로 인해 사용할 수 없으며 서버 인스턴스 수를 확장하는 것이 불가능합니다. 내결함성 목적. 또한 기본 포트 범위를 변경해야 합니다...

가능한 솔루션을 검색한 결과 다음이 선택되었습니다.

1. VPN이 포함된 포드는 노드별로 예약됩니다. hostNetwork, 즉 실제 IP에 연결됩니다.
2. 서비스는 다음을 통해 외부에 게시됩니다. ClusterIP. 포트는 노드에 물리적으로 설치되어 있으며, 약간의 예약(실제 IP 주소의 조건부 존재)을 통해 외부에서 액세스할 수 있습니다.
3. 포드가 상승한 노드를 결정하는 것은 우리 이야기의 범위를 벗어납니다. 상상력이 충분하다면 누구나 서비스를 노드에 단단히 "고정"하거나 VPN 서비스의 현재 IP 주소를 모니터링하고 클라이언트에 등록된 DNS 레코드를 편집하는 작은 사이드카 서비스를 작성할 수 있다고 말씀드리겠습니다.

라우팅 관점에서 VPN 서버가 발급한 IP 주소로 VPN 클라이언트를 고유하게 식별할 수 있습니다. 다음은 위에서 언급한 Redis에 설명된 서비스에 대한 클라이언트의 액세스를 제한하는 기본 예입니다.

apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: vpnclient-eth0
  labels:
    role: vpnclient
    environment: production
spec:
  interfaceName: "*"
  node: kube-02
  expectedIPs: ["172.176.176.2"]
---
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: vpn-rules
spec:
  selector: "role == 'vpnclient'"
  order: 0
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    protocol: TCP
    destination:
      ports: [6379]
  - action: Allow
    protocol: UDP
    destination:
      ports: [53, 67]

여기에서는 포트 6379에 연결하는 것이 엄격히 금지되어 있지만 동시에 DNS 서비스의 작동은 유지되며 규칙을 작성할 때 기능이 저하되는 경우가 많습니다. 앞서 언급했듯이 선택기가 나타나면 별도로 지정하지 않는 한 기본 거부 정책이 적용되기 때문입니다.

결과

따라서 Calico의 고급 API를 사용하면 클러스터 내부 및 주변의 라우팅을 유연하게 구성하고 동적으로 변경할 수 있습니다. 일반적으로 이 도구의 사용은 대포로 참새를 쏘는 것처럼 보일 수 있으며 BGP 및 IP-IP 터널을 사용하여 L3 네트워크를 구현하는 것은 플랫 네트워크에 간단한 Kubernetes 설치에서 괴물처럼 보입니다... 그러나 그렇지 않으면 도구가 상당히 실행 가능하고 유용해 보입니다. .

보안 요구 사항을 충족하기 위해 클러스터를 격리하는 것이 항상 가능한 것은 아니며 Calico(또는 유사한 솔루션)가 구출되는 곳입니다. 이 문서에 제공된 예제(사소한 수정 포함)는 AWS의 여러 클라이언트 설치에 사용됩니다.

PS

블로그에서도 읽어보세요.

• «보안 전문가를 위한 Kubernetes 네트워크 정책 소개";
• "Kubernetes의 네트워킹에 대한 그림 가이드": 파트 1 및 2(네트워크 모델, 오버레이 네트워크), 3부(서비스 및 트래픽 처리);
• «CNI(컨테이너 네트워킹 인터페이스) - Linux 컨테이너용 네트워크 인터페이스 및 표준".

출처 : habr.com