Giaosucan's blog - Chia sẻ kiến thức theo cách bá đạo

Ticker

20/recent/ticker-posts

Project Zeus - GCP Infrastructure - part 2


Google Kubernetes Engine (GKE) Series 2 – Setting up a CI/CD pipeline –  whereUcloud

Tiếp tục part 1, bài này giới thiệu về giải pháp xây dựng CICD infrastructure trên GCP của công ty ABC. 

Phân tích hệ thống hiện tại

Đầu tiên cần phân tích ưu nhược điểm của giải pháp hiện tại

Tool Jenkins là trái tim của hệ thống CICD được deploy trên K8s theo architect master/multi agent để leverage khả năng autoscaling của k8s.

Các project GCP được chia theo nhiêu môi trường như Dev, QA…Mỗi team sẽ có một Jenkins instance riêng và deploy trên 1 dedicated K8s cluster. 


Mô hình là Single Tenant GKE cluster có một số ưu điểm sau

  • Tách biệt hoàn toàn ứng dụng, dễ dàng kiểm soát cost trên từng cluster, theo từng team, project. 
  • Mỗi team owner từng Jenkins instance, họ có thể dễ dàng customize cluster theo nhu cầu, sử dụng tool riêng biệt

Tuy nhiên cũng có nhiều nhược điểm

  • Việc tự quản lý GCP cluster theo từng team đòi hỏi mỗi team phải có chuyên môn, kĩ năng nhất định trên GCP infrastructure
  • Chi phí tăng cao và khó kiểm soát, khi các team sử dụng nhiều resources hơn mức cần thiết. Do có full quyền trên cluster nên nhiều team đặt scaling node lên quá cao, tạo resources vô tội vạ. Nguy hiểm hơn nữa là leak security, một số resource trên K8s bị access từ internet do các team open port, firewall
  • Việc deploy resource được thực hiện thủ công bằng kubectl command line, dẫn tới nhiều sai sót như deploy nhầm, khó tracking

Kiến trúc K8s multi-tenant

Sau nhiều cuộc họp nội bộ cũng như nghe ý kiến tư vấn của đội SA của Google, team ABC quyết định chuyển đổi mô hình Single Tenant GKE sang Multi-tenant GKE như sau

Trong kiến trúc GKE Multi-tenants, mỗi môi trường (Dev, QA …) chỉ có một cluster k8s duy nhất, mỗi team người phát triển owner application sẽ được phân quyền theo namespaces. 

Ví dụ team CICD deploy và manage Jenkins sẽ owner namespace Jenkins, team backend manage backend thì owner namespace backend.

Kubernetes Role Based Access Controls (RBAC) cho phép team admin phân quyền cho từng team theo namespace theo kiến trúc sau. Gọi là namespace permission

Như vậy đã có sự thay đổi từ Cluster Permission (IAM based) sang namespace permission (K8S RBAC based) IAM based permission là phân quyền GCP resources dựa trên GCP service account.

Trong hệ thống mới chỉ có Infrastructure team mới có toàn quyền trên cluster (IAM based) bao gồm quyền R/W resources, namespaces, access namespaces của từng team. Các team khác chỉ được cấp quyền theo từng namespace của họ dùng RBAC based

Ví dụ, role Jenkins  (quyền get/list) sẽ được gán cho user service account cicd

kind: Role

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  namespace: jenkins                          # Namespace

  name: role-jenkins

rules:

- apiGroups: [""]

  resources: ["pods"]                         # The pod can be accessed.

  verbs: ["get", "list"]                      # The GET and LIST 

Để giải quyết việc các team có thể tùy tiện tạo resource trên namespaces dẫn tới cluster overhead, đội chi phí, Resource Quota và Limit Range được sử dụng. Khi user tạo resources, Resource Quota system sẽ tracking để đảm bảo không tạo quá resource cho phép 

Ví dụ SRE team sẽ setup Resource Quota trên namespace cho từng team, resource là limit RAM, CPU, diskspace 

CPU tối đa 1000, memory 200Gi

apiVersion: v1

kind: List

items:

- apiVersion: v1

  kind: ResourceQuota

  metadata:

    name: pods-high

  spec:

    hard:

      cpu: "1000"

      memory: 200Gi

      pods: "10"

Nếu user tạo resource vượt quá quota sẽ bị 403 forbidden. Tương tự thì LimitRange cho phép SRE team set up resource min/max cho từng team theo namespace

Tuy nhiên có một số challenging mà team gặp phải

  • Application isolation phức tạp hơn nhiều so với cluster isolation bởi vì một số app depend lẫn nhau. Ví dụ frontend depend vào backend, backend depend vào database. Database namespace bị lỗi khiến các app namespace khác ảnh hưởng theo
  • Làm thế nào quản lý billing resource trên từng namespace, team nào dùng bao nhiêu tiền resource
  • Chuyển đổi việc deploy resource manually bằng kubectl cli bằng công cụ tự động để tránh human mistake
  • Khi toàn bộ application (Jenkins, api gateway, backend … etc) được deploy vào cùng 1 GKE cluster thì bài toán autoscaling và HA, đặc biệt là security được đặt lên hàng đầu

Đón đọc phần tiếp của series

Đăng nhận xét

0 Nhận xét