Prohoster > Blog > quản lý > Cách chạy Istio bằng Kubernetes trong sản xuất. Phần 1

Cách chạy Istio bằng Kubernetes trong sản xuất. Phần 1

Cái gì Istio? Đây được gọi là Lưới dịch vụ, một công nghệ bổ sung thêm một lớp trừu tượng trên mạng. Chúng tôi chặn tất cả hoặc một phần lưu lượng truy cập trong cụm và thực hiện một số hoạt động nhất định với nó. Cái nào? Ví dụ: chúng tôi định tuyến thông minh hoặc chúng tôi triển khai phương pháp ngắt mạch, chúng tôi có thể tổ chức “triển khai canary”, chuyển một phần lưu lượng truy cập sang phiên bản dịch vụ mới hoặc chúng tôi có thể hạn chế các tương tác bên ngoài và kiểm soát tất cả các chuyến đi từ cụm đến cụm mạng bên ngoài. Có thể đặt các quy tắc chính sách để kiểm soát các chuyến đi giữa các dịch vụ siêu nhỏ khác nhau. Cuối cùng, chúng ta có thể lấy toàn bộ bản đồ tương tác mạng và làm cho bộ sưu tập thống nhất các số liệu hoàn toàn trong suốt đối với các ứng dụng.

Bạn có thể đọc về cơ chế làm việc trong tài liệu chính thức. Istio là một công cụ thực sự mạnh mẽ cho phép bạn giải quyết nhiều nhiệm vụ và vấn đề. Trong bài viết này, tôi muốn trả lời các câu hỏi chính thường phát sinh khi bắt đầu với Istio. Điều này sẽ giúp bạn xử lý nhanh hơn.

Cách chạy Istio bằng Kubernetes trong sản xuất. Phần 1

Nguyên tắc hoạt động

Istio bao gồm hai khu vực chính - mặt phẳng điều khiển và mặt phẳng dữ liệu. Mặt phẳng điều khiển chứa các thành phần chính đảm bảo hoạt động chính xác của phần còn lại. Ở phiên bản hiện tại (1.0) máy bay điều khiển có XNUMX thành phần chính: Pilot, Mixer, Citadel. Chúng tôi sẽ không xem xét Citadel, cần phải tạo chứng chỉ để đảm bảo TLS lẫn nhau giữa các dịch vụ. Chúng ta hãy xem xét kỹ hơn về thiết bị và mục đích của Pilot và Mixer.

Cách chạy Istio bằng Kubernetes trong sản xuất. Phần 1

Pilot là thành phần điều khiển chính phân phối tất cả thông tin về những gì chúng tôi có trong cụm - dịch vụ, điểm cuối và quy tắc định tuyến của chúng (ví dụ: quy tắc triển khai Canary hoặc quy tắc ngắt mạch).

Bộ trộn là một thành phần mặt phẳng điều khiển tùy chọn cung cấp khả năng thu thập số liệu, nhật ký và bất kỳ thông tin nào về tương tác mạng. Ông cũng giám sát việc tuân thủ các quy tắc Chính sách và tuân thủ giới hạn tỷ lệ.

Mặt phẳng dữ liệu được triển khai bằng cách sử dụng các thùng chứa proxy sidecar. Mạnh mẽ được sử dụng theo mặc định. phái viên đại diện. Nó có thể được thay thế bằng cách triển khai khác, chẳng hạn như nginx (nginmesh).

Để Istio hoạt động hoàn toàn trong suốt đối với các ứng dụng, có một hệ thống tiêm tự động. Việc triển khai mới nhất phù hợp với các phiên bản Kubernetes 1.9+ (webhook nhập học đột biến). Đối với Kubernetes phiên bản 1.7, 1.8, có thể sử dụng Trình khởi tạo.

Các thùng chứa Sidecar được kết nối với Pilot bằng giao thức GRPC, cho phép bạn tối ưu hóa mô hình đẩy cho các thay đổi xảy ra trong cụm. GRPC đã được sử dụng trong Envoy kể từ phiên bản 1.6, trong Istio, nó đã được sử dụng từ phiên bản 0.8 và là một tác nhân thí điểm - một trình bao bọc golang trên đặc phái viên để định cấu hình các tùy chọn khởi chạy.

Pilot và Mixer là các thành phần hoàn toàn không trạng thái, tất cả trạng thái được lưu trong bộ nhớ. Cấu hình cho chúng được đặt ở dạng Tài nguyên tùy chỉnh Kubernetes, được lưu trữ trong etcd.
Istio-agent lấy địa chỉ của Pilot và mở luồng GRPC tới địa chỉ đó.

Như tôi đã nói, Istio thực hiện tất cả các chức năng hoàn toàn trong suốt đối với các ứng dụng. Hãy xem làm thế nào. Thuật toán là thế này:

  1. Triển khai phiên bản mới của dịch vụ.
  2. Tùy thuộc vào phương pháp tiêm bộ chứa sidecar, bộ chứa istio-init và bộ chứa tác nhân istio (đặc phái viên) được thêm vào ở giai đoạn ứng dụng cấu hình hoặc chúng đã có thể được chèn thủ công vào mô tả của thực thể Kubernetes Pod.
  3. Bộ chứa istio-init là một tập lệnh áp dụng các quy tắc iptables cho nhóm. Có hai tùy chọn để định cấu hình lưu lượng truy cập được gói trong bộ chứa istio-agent: sử dụng quy tắc chuyển hướng iptables hoặc TPROXY. Tại thời điểm viết bài, cách tiếp cận mặc định là với các quy tắc chuyển hướng. Trong istio-init, có thể định cấu hình lưu lượng truy cập nào sẽ bị chặn và gửi tới tác nhân istio. Ví dụ: để chặn tất cả lưu lượng truy cập vào và ra, bạn cần đặt tham số -i и -b thành ý nghĩa *. Bạn có thể chỉ định các cổng cụ thể để chặn. Để không chặn một mạng con cụ thể, bạn có thể chỉ định nó bằng cờ -x.
  4. Sau khi các vùng chứa init được thực thi, các vùng chứa chính sẽ được khởi chạy, bao gồm cả tác nhân hoa tiêu (đặc phái viên). Nó kết nối với Pilot đã được triển khai thông qua GRPC và nhận thông tin về tất cả các dịch vụ và chính sách định tuyến hiện có trong cụm. Theo dữ liệu nhận được, anh ấy định cấu hình các cụm và gán chúng trực tiếp cho các điểm cuối của ứng dụng của chúng tôi trong cụm Kubernetes. Cũng cần lưu ý một điểm quan trọng: đặc phái viên tự động cấu hình các trình nghe (IP, cặp cổng) mà nó bắt đầu nghe. Do đó, khi các yêu cầu vào nhóm, được chuyển hướng bằng cách sử dụng các quy tắc iptables chuyển hướng trong sidecar, đặc phái viên đã có thể xử lý thành công các kết nối này và hiểu nơi để ủy quyền thêm lưu lượng truy cập. Cũng ở giai đoạn này, thông tin được gửi đến Bộ trộn mà chúng ta sẽ xem xét sau và các nhịp theo dõi được gửi đi.

Kết quả là, chúng tôi có được toàn bộ mạng máy chủ proxy đặc phái viên mà chúng tôi có thể định cấu hình từ một điểm (Thí điểm). Tất cả các yêu cầu trong và ngoài nước đều thông qua phái viên. Hơn nữa, chỉ lưu lượng TCP bị chặn. Điều này có nghĩa là IP dịch vụ Kubernetes được phân giải bằng kube-dns qua UDP mà không thay đổi. Sau đó, sau khi giải quyết xong, yêu cầu gửi đi sẽ bị chặn và xử lý bởi đặc phái viên, người đã quyết định xem yêu cầu sẽ được gửi đến điểm cuối nào (hoặc không được gửi, trong trường hợp chính sách truy cập hoặc bộ ngắt mạch của thuật toán).

Chúng tôi đã tìm ra Pilot, bây giờ chúng tôi cần hiểu cách thức hoạt động của Mixer và tại sao nó lại cần thiết. Bạn có thể đọc tài liệu chính thức cho nó đây.

Bộ trộn ở dạng hiện tại bao gồm hai thành phần: istio-telemetry, istio-policy (trước phiên bản 0.8, nó là một thành phần istio-mixer). Cả hai đều là máy trộn, mỗi người chịu trách nhiệm cho nhiệm vụ riêng của mình. Phép đo từ xa Istio nhận thông tin về việc ai sẽ đi đâu và với thông số gì từ thùng chứa Báo cáo sidecar thông qua GRPC. Chính sách Istio chấp nhận các yêu cầu Kiểm tra để xác minh rằng các quy tắc Chính sách được đáp ứng. Tất nhiên, kiểm tra chính sách không được thực hiện cho mọi yêu cầu mà được lưu vào bộ đệm trên máy khách (trong sidecar) trong một thời gian nhất định. Kiểm tra báo cáo được gửi dưới dạng yêu cầu hàng loạt. Hãy xem cách định cấu hình và những thông số nào sẽ được gửi sau.

Bộ trộn được coi là một thành phần có tính sẵn sàng cao, đảm bảo công việc lắp ráp và xử lý dữ liệu từ xa không bị gián đoạn. Hệ thống thu được kết quả là một bộ đệm đa cấp. Ban đầu, dữ liệu được lưu vào bộ đệm ở phía sidecar của các thùng chứa, sau đó ở phía bộ trộn và sau đó được gửi đến cái gọi là phần phụ trợ của bộ trộn. Kết quả là, nếu bất kỳ thành phần hệ thống nào bị lỗi, bộ đệm sẽ tăng lên và bị xóa sau khi hệ thống được khôi phục. Phần phụ trợ của bộ trộn là điểm cuối để gửi dữ liệu từ xa: statsd, newrelic, v.v. Bạn có thể viết chương trình phụ trợ của riêng mình, việc này khá đơn giản và chúng ta sẽ xem cách thực hiện.

Cách chạy Istio bằng Kubernetes trong sản xuất. Phần 1

Tóm lại, sơ đồ làm việc với phép đo từ xa istio như sau.

  1. Dịch vụ 1 gửi yêu cầu đến dịch vụ 2.
  2. Khi rời khỏi dịch vụ 1, yêu cầu được gói gọn trong sidecar của chính nó.
  3. Phái viên Sidecar theo dõi cách yêu cầu chuyển sang dịch vụ 2 và chuẩn bị các thông tin cần thiết.
  4. Sau đó gửi nó đến phép đo từ xa bằng cách sử dụng yêu cầu Báo cáo.
  5. Istio-telemetry xác định xem Báo cáo này có nên được gửi đến các phụ trợ hay không, nên gửi dữ liệu nào và dữ liệu nào.
  6. Istio-telemetry gửi dữ liệu Báo cáo đến phụ trợ nếu cần.

Bây giờ hãy xem cách triển khai Istio trong hệ thống, chỉ bao gồm các thành phần chính (Phi công và đặc phái viên phụ xe).

Trước tiên, hãy xem cấu hình chính (lưới) mà Pilot đọc:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio
  namespace: istio-system
  labels:
    app: istio
    service: istio
data:
  mesh: |-

    # пока что не включаем отправку tracing информации (pilot настроит envoy’и таким образом, что отправка не будет происходить)
    enableTracing: false

    # пока что не указываем mixer endpoint’ы, чтобы sidecar контейнеры не отправляли информацию туда
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # ставим временной промежуток, с которым будет envoy переспрашивать Pilot (это для старой версии envoy proxy)
    rdsRefreshDelay: 5s

    # default конфигурация для envoy sidecar
    defaultConfig:
      # аналогично как rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # оставляем по умолчанию (путь к конфигурации и бинарю envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # дефолтное имя запущенного sidecar контейнера (используется, например, в именах сервиса при отправке tracing span’ов)
      serviceCluster: istio-proxy

      # время, которое будет ждать envoy до того, как он принудительно завершит все установленные соединения
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # по умолчанию используются REDIRECT правила iptables. Можно изменить на TPROXY.
      #interceptionMode: REDIRECT

      # Порт, на котором будет запущена admin панель каждого sidecar контейнера (envoy)
      proxyAdminPort: 15000

      # адрес, по которому будут отправляться trace’ы по zipkin протоколу (в начале мы отключили саму отправку, поэтому это поле сейчас не будет использоваться)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd адрес для отправки метрик envoy контейнеров (отключаем)
      # statsdUdpAddress: aggregator:8126

      # выключаем поддержку опции Mutual TLS
      controlPlaneAuthPolicy: NONE

      # адрес, на котором будет слушать istio-pilot для того, чтобы сообщать информацию о service discovery всем sidecar контейнерам
      discoveryAddress: istio-pilot.istio-system:15007

Tất cả các thành phần điều khiển chính (mặt phẳng điều khiển) sẽ được đặt trong không gian tên istio-system trong Kubernetes.

Ở mức tối thiểu, chúng ta chỉ cần triển khai Pilot. Đối với điều này, chúng tôi sử dụng một cấu hình như vậy.

Và chúng tôi sẽ định cấu hình thủ công sidecar tiêm của vùng chứa.

Vùng chứa ban đầu:

initContainers:
 - name: istio-init
   args:
   - -p
   - "15001"
   - -u
   - "1337"
   - -m
   - REDIRECT
   - -i
   - '*'
   - -b
   - '*'
   - -d
   - ""
   image: istio/proxy_init:1.0.0
   imagePullPolicy: IfNotPresent
   resources:
     limits:
       memory: 128Mi
   securityContext:
     capabilities:
       add:
       - NET_ADMIN

Và xe phụ:

       name: istio-proxy
       args:
         - "bash"
         - "-c"
         - |
           exec /usr/local/bin/pilot-agent proxy sidecar 
           --configPath 
           /etc/istio/proxy 
           --binaryPath 
           /usr/local/bin/envoy 
           --serviceCluster 
           service-name 
           --drainDuration 
           45s 
           --parentShutdownDuration 
           1m0s 
           --discoveryAddress 
           istio-pilot.istio-system:15007 
           --discoveryRefreshDelay 
           1s 
           --connectTimeout 
           10s 
           --proxyAdminPort 
           "15000" 
           --controlPlaneAuthPolicy 
           NONE
         env:
         - name: POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: POD_NAMESPACE
           valueFrom:
             fieldRef:
               fieldPath: metadata.namespace
         - name: INSTANCE_IP
           valueFrom:
             fieldRef:
               fieldPath: status.podIP
         - name: ISTIO_META_POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: ISTIO_META_INTERCEPTION_MODE
           value: REDIRECT
         image: istio/proxyv2:1.0.0
         imagePullPolicy: IfNotPresent
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             memory: 2048Mi
         securityContext:
           privileged: false
           readOnlyRootFilesystem: true
           runAsUser: 1337
         volumeMounts:
         - mountPath: /etc/istio/proxy
           name: istio-envoy

Để mọi thứ bắt đầu thành công, bạn cần tạo ServiceAccount, ClusterRole, ClusterRoleBinding, CRD cho Pilot, có thể tìm thấy các mô tả về chúng đây.

Do đó, dịch vụ mà chúng tôi đưa vào sidecar với đặc phái viên sẽ bắt đầu thành công, nhận được tất cả khám phá từ phi công và xử lý các yêu cầu.

Điều quan trọng là phải hiểu rằng tất cả các thành phần của mặt phẳng điều khiển là các ứng dụng không trạng thái và có thể được thu nhỏ theo chiều ngang mà không gặp sự cố. Tất cả dữ liệu được lưu trữ trong etcd dưới dạng mô tả tùy chỉnh của tài nguyên Kubernetes.

Ngoài ra, Istio (vẫn đang thử nghiệm) có khả năng chạy bên ngoài cụm và khả năng theo dõi và dò tìm dịch vụ khám phá giữa một số cụm Kubernetes. Bạn có thể đọc thêm về điều này đây.

Đối với cài đặt nhiều cụm, hãy lưu ý các giới hạn sau:

  1. CIDR nhóm và CIDR dịch vụ phải là duy nhất trên tất cả các cụm và không được chồng chéo.
  2. Tất cả các Nhóm CIDR phải có thể truy cập được từ bất kỳ Nhóm CIDR nào giữa các cụm.
  3. Tất cả các máy chủ API Kubernetes phải có thể truy cập lẫn nhau.

Đây là thông tin ban đầu để giúp bạn bắt đầu với Istio. Tuy nhiên, vẫn còn nhiều cạm bẫy. Ví dụ: các tính năng định tuyến lưu lượng truy cập bên ngoài (bên ngoài cụm), cách tiếp cận để gỡ lỗi sidecar, lập hồ sơ, thiết lập bộ trộn và viết phụ trợ bộ trộn tùy chỉnh, thiết lập cơ chế theo dõi và hoạt động của nó bằng cách sử dụng đặc phái viên.
Tất cả điều này chúng tôi sẽ xem xét trong các ấn phẩm sau. Đặt câu hỏi của bạn, tôi sẽ cố gắng bao gồm chúng.

Nguồn: www.habr.com

Thêm một lời nhận xét