Chạy ProxySQL dưới dạng Vùng chứa trợ giúp trên Kubernetes

ProxySQL thường nằm giữa các tầng ứng dụng và cơ sở dữ liệu, được gọi là tầng proxy ngược. Khi các vùng chứa ứng dụng của bạn được điều phối và quản lý bởi Kubernetes, bạn có thể muốn sử dụng ProxySQL trước các máy chủ cơ sở dữ liệu của mình.

Trong bài đăng này, chúng tôi sẽ hướng dẫn bạn cách chạy ProxySQL trên Kubernetes như một vùng chứa trợ giúp trong một nhóm. Chúng tôi sẽ sử dụng Wordpress làm ứng dụng ví dụ. Dịch vụ dữ liệu được cung cấp bởi MySQL Replication hai nút của chúng tôi, được triển khai bằng ClusterControl và nằm bên ngoài mạng Kubernetes trên cơ sở hạ tầng kim loại trần, như được minh họa trong sơ đồ sau:

Hình ảnh Docker ProxySQL

Trong ví dụ này, chúng tôi sẽ sử dụng hình ảnh ProxySQL Docker được duy trì bởi Somenines, một hình ảnh công cộng chung được xây dựng để sử dụng đa mục đích. Hình ảnh không có tập lệnh entrypoint và hỗ trợ Galera Cluster (ngoài hỗ trợ tích hợp sẵn cho MySQL Replication), trong đó cần có tập lệnh bổ sung cho mục đích kiểm tra sức khỏe.

Về cơ bản, để chạy vùng chứa ProxySQL, chỉ cần thực hiện lệnh sau:

$ docker run -d -v /path/to/proxysql.cnf:/etc/proxysql.cnf severalnines/proxysql

Hình ảnh này khuyên bạn nên liên kết tệp cấu hình ProxySQL với điểm gắn kết, /etc/proxysql.cnf, mặc dù bạn có thể bỏ qua và định cấu hình nó sau bằng Bảng điều khiển dành cho quản trị viên ProxySQL. Các cấu hình mẫu được cung cấp trong trang Docker Hub hoặc trang Github.

ProxySQL trên Kubernetes

Thiết kế kiến trúc ProxySQL là một chủ đề chủ quan và phụ thuộc nhiều vào vị trí của ứng dụng và vùng chứa cơ sở dữ liệu cũng như vai trò của chính ProxySQL. ProxySQL không chỉ định tuyến các truy vấn, nó còn có thể được sử dụng để viết lại và lưu vào bộ nhớ cache các truy vấn. Số lần truy cập bộ nhớ cache hiệu quả có thể yêu cầu cấu hình tùy chỉnh được thiết kế riêng cho khối lượng công việc của cơ sở dữ liệu ứng dụng.

Lý tưởng nhất là chúng ta có thể định cấu hình ProxySQL được Kubernetes quản lý bằng hai cấu hình:

ProxySQL dưới dạng dịch vụ Kubernetes (triển khai tập trung).
ProxySQL như một vùng chứa trợ giúp trong một nhóm (triển khai phân tán).

Tùy chọn đầu tiên khá đơn giản, trong đó chúng tôi tạo một ProxySQL pod và đính kèm dịch vụ Kubernetes vào đó. Các ứng dụng sau đó sẽ kết nối với dịch vụ ProxySQL thông qua mạng trên các cổng được cấu hình. Mặc định là 6033 cho cổng cân bằng tải MySQL và 6032 cho cổng quản trị ProxySQL. Việc triển khai này sẽ được đề cập trong bài đăng trên blog sắp tới.

Tùy chọn thứ hai hơi khác một chút. Kubernetes có một khái niệm gọi là "pod". Bạn có thể có một hoặc nhiều thùng chứa cho mỗi nhóm, chúng được kết hợp tương đối chặt chẽ. Nội dung của nhóm luôn được đặt cùng vị trí và đồng thời lên lịch và chạy trong bối cảnh chung. Một nhóm là đơn vị vùng chứa nhỏ nhất có thể quản lý được trong Kubernetes.

Có thể dễ dàng phân biệt cả hai cách triển khai bằng cách nhìn vào sơ đồ sau:

Lý do chính mà các nhóm có thể có nhiều vùng chứa là để hỗ trợ các ứng dụng trợ giúp hỗ trợ một ứng dụng chính. Ví dụ điển hình của các ứng dụng trợ giúp là bộ kéo dữ liệu, bộ đẩy dữ liệu và proxy. Người trợ giúp và ứng dụng chính thường cần giao tiếp với nhau. Thông thường, điều này được thực hiện thông qua hệ thống tệp được chia sẻ, như được hiển thị trong bài tập này, hoặc thông qua giao diện mạng loopback, localhost. Ví dụ về mẫu này là máy chủ web cùng với chương trình trợ giúp thăm dò ý kiến của kho lưu trữ Git về các bản cập nhật mới.

Bài đăng trên blog này sẽ đề cập đến cấu hình thứ hai - chạy ProxySQL như một vùng chứa trợ giúp trong một nhóm.

ProxySQL với tư cách là Người trợ giúp trong một Pod

Trong thiết lập này, chúng tôi chạy ProxySQL như một vùng chứa trợ giúp cho vùng chứa Wordpress của chúng tôi. Sơ đồ sau minh họa kiến trúc cấp cao của chúng tôi:

Trong thiết lập này, vùng chứa ProxySQL được kết hợp chặt chẽ với vùng chứa Wordpress và chúng tôi đặt tên nó là nhóm "blog". Nếu việc lên lịch lại xảy ra, ví dụ:nút công nhân Kubernetes bị hỏng, hai vùng chứa này sẽ luôn được lên lịch lại cùng nhau như một đơn vị logic trên máy chủ khả dụng tiếp theo. Để giữ cho nội dung của vùng chứa ứng dụng liên tục trên nhiều nút, chúng tôi phải sử dụng hệ thống tệp được phân cụm hoặc từ xa, trong trường hợp này là NFS.

Vai trò của ProxySQL là cung cấp một lớp trừu tượng cơ sở dữ liệu cho vùng chứa ứng dụng. Vì chúng tôi đang chạy MySQL Replication hai nút làm dịch vụ cơ sở dữ liệu phụ trợ, việc phân tách đọc-ghi là rất quan trọng để tối đa hóa mức tiêu thụ tài nguyên trên cả hai máy chủ MySQL. ProxySQL vượt trội về điều này và yêu cầu tối thiểu hoặc không có thay đổi đối với ứng dụng.

Có một số lợi ích khác khi chạy ProxySQL trong thiết lập này:

Mang khả năng lưu vào bộ nhớ đệm truy vấn gần nhất với lớp ứng dụng đang chạy trong Kubernetes.
Triển khai an toàn bằng cách kết nối thông qua tệp ổ cắm ProxySQL UNIX. Nó giống như một đường ống mà máy chủ và máy khách có thể sử dụng để kết nối và trao đổi các yêu cầu cũng như dữ liệu.
Cấp proxy ngược được phân phối với kiến trúc không có gì được chia sẻ.
Ít chi phí mạng hơn do triển khai "bỏ qua mạng".
Phương pháp triển khai không trạng thái bằng cách sử dụng Kubernetes ConfigMaps.

Chuẩn bị cơ sở dữ liệu

Tạo cơ sở dữ liệu và người dùng wordpress trên bản chính và gán đặc quyền chính xác:

mysql-master> CREATE DATABASE wordpress;
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'passw0rd';
mysql-master> GRANT ALL PRIVILEGES ON wordpress.* TO [email protected]'%';

Ngoài ra, hãy tạo người dùng giám sát ProxySQL:

mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'proxysqlpassw0rd';

Sau đó, tải lại bảng tài trợ:

mysql-master> FLUSH PRIVILEGES;

Chuẩn bị Pod

Bây giờ, hãy sao chép, dán các dòng sau vào một tệp có tên là blog-deploy.yml trên máy chủ nơi kubectl được định cấu hình:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: blog
  labels:
    app: blog
spec:
  replicas: 1
  selector:
    matchLabels:
      app: blog
      tier: frontend
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: blog
        tier: frontend
    spec:

      restartPolicy: Always

      containers:
      - image: wordpress:4.9-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: localhost:/tmp/proxysql.sock
        - name: WORDPRESS_DB_USER
          value: wordpress
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
        - name: shared-data
          mountPath: /tmp

      - image: severalnines/proxysql
        name: proxysql
        volumeMounts:
        - name: proxysql-config
          mountPath: /etc/proxysql.cnf
          subPath: proxysql.cnf
        - name: shared-data
          mountPath: /tmp

      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim
      - name: proxysql-config
        configMap:
          name: proxysql-configmap
      - name: shared-data
        emptyDir: {}

Tệp YAML có nhiều dòng và chúng ta hãy chỉ xem phần thú vị. Phần đầu tiên:

apiVersion: apps/v1
kind: Deployment

Dòng đầu tiên là apiVersion. Cụm Kubernetes của chúng tôi đang chạy trên v1.12, vì vậy chúng tôi nên tham khảo tài liệu về API Kubernetes v1.12 và thực hiện theo khai báo tài nguyên theo API này. Tiếp theo là loại, cho biết loại tài nguyên mà chúng ta muốn triển khai. Triển khai, Dịch vụ, ReplicaSet, DaemonSet, PersentlyVolume là một số ví dụ.

Phần quan trọng tiếp theo là phần "container". Ở đây chúng tôi xác định tất cả các vùng chứa mà chúng tôi muốn chạy cùng nhau trong nhóm này. Phần đầu tiên là vùng chứa Wordpress:

      - image: wordpress:4.9-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: localhost:/tmp/proxysql.sock
        - name: WORDPRESS_DB_USER
          value: wordpress
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
        - name: shared-data
          mountPath: /tmp

Trong phần này, chúng tôi yêu cầu Kubernetes triển khai Wordpress 4.9 bằng máy chủ web Apache và chúng tôi đã đặt tên cho vùng chứa là "wordpress". Chúng tôi cũng muốn Kubernetes chuyển một số biến môi trường:

WORDPRESS_DB_HOST - Máy chủ cơ sở dữ liệu. Vì vùng chứa ProxySQL của chúng tôi nằm trong cùng một Pod với vùng chứa Wordpress, nên thay vào đó, sử dụng tệp ổ cắm ProxySQL sẽ an toàn hơn. Định dạng để sử dụng tệp socket trong Wordpress là "localhost:{đường dẫn đến tệp socket}". Theo mặc định, nó nằm trong thư mục / tmp của vùng chứa ProxySQL. Đường dẫn / tmp này được chia sẻ giữa các vùng chứa Wordpress và ProxySQL bằng cách sử dụng volumeMounts "dữ liệu được chia sẻ" như được hiển thị bên dưới. Cả hai vùng chứa đều phải gắn kết tập này để chia sẻ cùng một nội dung trong thư mục / tmp.
WORDPRESS_DB_USER - Chỉ định người dùng cơ sở dữ liệu wordpress.
WORDPRESS_DB_PASSWORD - Mật khẩu cho WORDPRESS_DB_USER . Vì chúng tôi không muốn để lộ mật khẩu trong tệp này, chúng tôi có thể ẩn nó bằng cách sử dụng Kubernetes Secrets. Ở đây, chúng tôi hướng dẫn Kubernetes đọc tài nguyên Bí mật "mysql-pass" để thay thế. Các bí mật phải được tạo nâng cao trước khi triển khai nhóm, như đã giải thích thêm.

Chúng tôi cũng muốn xuất bản cổng 80 của vùng chứa cho người dùng cuối. Nội dung Wordpress được lưu trữ bên trong / var / www / html trong vùng chứa sẽ được gắn vào bộ nhớ liên tục chạy trên NFS của chúng tôi.

Tiếp theo, chúng tôi xác định vùng chứa ProxySQL:

      - image: severalnines/proxysql:1.4.12
        name: proxysql
        volumeMounts:
        - name: proxysql-config
          mountPath: /etc/proxysql.cnf
          subPath: proxysql.cnf
        - name: shared-data
          mountPath: /tmp
        ports:
        - containerPort: 6033
          name: proxysql

Trong phần trên, chúng tôi đang yêu cầu Kubernetes triển khai ProxySQL bằng cách sử dụng vàinines / proxysql phiên bản hình ảnh 1.4.12. Chúng tôi cũng muốn Kubernetes gắn tệp cấu hình tùy chỉnh, được định cấu hình trước của chúng tôi và ánh xạ nó tới /etc/proxysql.cnf bên trong vùng chứa. Sẽ có một khối gọi là "shared-data" ánh xạ tới thư mục / tmp để chia sẻ với hình ảnh Wordpress - một thư mục tạm thời chia sẻ thời gian tồn tại của pod. Điều này cho phép vùng chứa Wordpress sử dụng tệp socket ProxySQL (/tmp/proxysql.sock) khi kết nối với cơ sở dữ liệu, bỏ qua mạng TCP / IP.

Phần cuối cùng là phần "tập":

      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim
      - name: proxysql-config
        configMap:
          name: proxysql-configmap
      - name: shared-data
        emptyDir: {}

Kubernetes sẽ phải tạo ba tập cho nhóm này:

wordpress-dai dẳng-lưu trữ - Sử dụng PersentlyVolumeClaim tài nguyên để ánh xạ quá trình xuất NFS vào vùng chứa để lưu trữ dữ liệu liên tục cho nội dung Wordpress.
proxysql-config - Sử dụng Bản đồ cấu hình tài nguyên để ánh xạ tệp cấu hình ProxySQL.
dữ liệu được chia sẻ - Sử dụng blankDir tài nguyên để gắn kết một thư mục được chia sẻ cho các vùng chứa của chúng tôi bên trong Pod. blankDir tài nguyên là một thư mục tạm thời chia sẻ thời gian tồn tại của nhóm.

Do đó, dựa trên định nghĩa YAML của chúng tôi ở trên, chúng tôi phải chuẩn bị một số tài nguyên Kubernetes trước khi có thể bắt đầu triển khai nhóm "blog":

PersentlyVolume và PersentlyVolumeClaim - Để lưu trữ nội dung web của ứng dụng Wordpress của chúng tôi, vì vậy khi nhóm đang được lên lịch lại đến nút công nhân khác, chúng tôi sẽ không mất các thay đổi cuối cùng.
Bí mật - Để ẩn mật khẩu người dùng cơ sở dữ liệu Wordpress bên trong tệp YAML.
Bản đồ cấu hình - Để ánh xạ tệp cấu hình tới vùng chứa ProxySQL, vì vậy khi nó được lên lịch lại đến nút khác, Kubernetes có thể tự động gắn lại tệp đó một lần nữa.

Somenines MySQL trên Docker:Cách chứa cơ sở dữ liệu của bạn Khám phá tất cả những gì bạn cần hiểu khi cân nhắc chạy dịch vụ MySQL trên ảo hóa vùng chứa DockerTải xuống Whitepaper

PersentlyVolume và dai dẳngVolumeClaim

Tất cả các nút Kubernetes trong cụm đều có thể truy cập được một bộ lưu trữ liên tục tốt cho Kubernetes. Vì lợi ích của bài đăng trên blog này, chúng tôi đã sử dụng NFS làm nhà cung cấp PersentlyVolume (PV) vì nó dễ dàng và được hỗ trợ ngay từ đầu. Máy chủ NFS được đặt ở đâu đó bên ngoài mạng Kubernetes của chúng tôi và chúng tôi đã định cấu hình nó để cho phép tất cả các nút Kubernetes với dòng sau bên trong / etc / export:

/nfs    192.168.55.*(rw,sync,no_root_squash,no_all_squash)

Lưu ý rằng gói máy khách NFS phải được cài đặt trên tất cả các nút Kubernetes. Nếu không, Kubernetes sẽ không thể gắn NFS một cách chính xác. Trên tất cả các nút:

$ sudo apt-install nfs-common #Ubuntu/Debian
$ yum install nfs-utils #RHEL/CentOS

Ngoài ra, hãy đảm bảo rằng trên máy chủ NFS, thư mục đích tồn tại:

(nfs-server)$ mkdir /nfs/kubernetes/wordpress

Sau đó, tạo một tệp có tên wordpress-pv-pvc.yml và thêm các dòng sau:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: wp-pv
  labels:
    app: blog
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 3Gi
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /nfs/kubernetes/wordpress
    server: 192.168.55.200
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: wp-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi
  selector:
    matchLabels:
      app: blog
      tier: frontend

Theo định nghĩa trên, chúng tôi muốn Kubernetes phân bổ 3GB dung lượng ổ đĩa trên máy chủ NFS cho vùng chứa Wordpress của chúng tôi. Lưu ý đối với việc sử dụng sản xuất, NFS nên được định cấu hình với trình cấp phép tự động và lớp lưu trữ.

Tạo nguồn PV và PVC:

$ kubectl create -f wordpress-pv-pvc.yml

Xác minh xem các tài nguyên đó có được tạo hay không và trạng thái phải là "Đã ràng buộc":

$ kubectl get pv,pvc
NAME                     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
persistentvolume/wp-pv   3Gi        RWO            Recycle          Bound    default/wp-pvc                           22h

NAME                           STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/wp-pvc   Bound    wp-pv    3Gi        RWO                           22h

Bí mật

Cách đầu tiên là tạo một bí mật để được sử dụng bởi vùng chứa Wordpress cho WORDPRESS_DB_PASSWORD biến môi trường. Lý do đơn giản là vì chúng tôi không muốn để lộ mật khẩu dưới dạng văn bản rõ ràng bên trong tệp YAML.

Tạo một tài nguyên bí mật được gọi là mysql-pass và chuyển mật khẩu tương ứng:

$ kubectl create secret generic mysql-pass --from-literal=password=passw0rd

Xác minh rằng bí mật của chúng tôi được tạo ra:

$ kubectl get secrets mysql-pass
NAME         TYPE     DATA   AGE
mysql-pass   Opaque   1      7h12m

Bản đồ cấu hình

Chúng tôi cũng cần tạo tài nguyên Bản đồ cấu hình cho vùng chứa ProxySQL của chúng tôi. Tệp Kubernetes ConfigMap chứa các cặp khóa-giá trị của dữ liệu cấu hình có thể được sử dụng trong các nhóm hoặc được sử dụng để lưu trữ dữ liệu cấu hình. ConfigMaps cho phép bạn tách các thành phần cấu hình khỏi nội dung hình ảnh để giữ cho các ứng dụng được chứa trong vùng có thể di động được.

Vì máy chủ cơ sở dữ liệu của chúng tôi đã chạy trên các máy chủ trần với tên máy chủ và địa chỉ IP tĩnh cùng với tên người dùng và mật khẩu giám sát tĩnh, nên trong trường hợp sử dụng này, tệp ConfigMap sẽ lưu trữ thông tin cấu hình được định cấu hình trước về dịch vụ ProxySQL mà chúng tôi muốn sử dụng.

Đầu tiên, hãy tạo một tệp văn bản có tên là proxysql.cnf và thêm các dòng sau:

datadir="/var/lib/proxysql"
admin_variables=
{
        admin_credentials="admin:adminpassw0rd"
        mysql_ifaces="0.0.0.0:6032"
        refresh_interval=2000
}
mysql_variables=
{
        threads=4
        max_connections=2048
        default_query_delay=0
        default_query_timeout=36000000
        have_compress=true
        poll_timeout=2000
        interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
        default_schema="information_schema"
        stacksize=1048576
        server_version="5.1.30"
        connect_timeout_server=10000
        monitor_history=60000
        monitor_connect_interval=200000
        monitor_ping_interval=200000
        ping_interval_server_msec=10000
        ping_timeout_server=200
        commands_stats=true
        sessions_sort=true
        monitor_username="proxysql"
        monitor_password="proxysqlpassw0rd"
}
mysql_servers =
(
        { address="192.168.55.171" , port=3306 , hostgroup=10, max_connections=100 },
        { address="192.168.55.172" , port=3306 , hostgroup=10, max_connections=100 },
        { address="192.168.55.171" , port=3306 , hostgroup=20, max_connections=100 },
        { address="192.168.55.172" , port=3306 , hostgroup=20, max_connections=100 }
)
mysql_users =
(
        { username = "wordpress" , password = "passw0rd" , default_hostgroup = 10 , active = 1 }
)
mysql_query_rules =
(
        {
                rule_id=100
                active=1
                match_pattern="^SELECT .* FOR UPDATE"
                destination_hostgroup=10
                apply=1
        },
        {
                rule_id=200
                active=1
                match_pattern="^SELECT .*"
                destination_hostgroup=20
                apply=1
        },
        {
                rule_id=300
                active=1
                match_pattern=".*"
                destination_hostgroup=10
                apply=1
        }
)
mysql_replication_hostgroups =
(
        { writer_hostgroup=10, reader_hostgroup=20, comment="MySQL Replication 5.7" }
)

Chú ý thêm đến phần "mysql_servers" và "mysql_users", nơi bạn có thể cần phải sửa đổi các giá trị cho phù hợp với thiết lập cụm cơ sở dữ liệu của mình. Trong trường hợp này, chúng tôi có hai máy chủ cơ sở dữ liệu đang chạy trong MySQL Replication như được tóm tắt trong ảnh chụp màn hình Topology sau được lấy từ ClusterControl:

Tất cả các lần ghi phải chuyển đến nút chính trong khi các lần đọc được chuyển tiếp đến nhóm máy chủ 20, như được định nghĩa trong phần "mysql_query_rules". Đó là điều cơ bản của phân tách đọc / ghi và chúng tôi muốn sử dụng chúng hoàn toàn.

Sau đó, nhập tệp cấu hình vào Bản đồ cấu hình:

$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf
configmap/proxysql-configmap created

Xác minh xem Bản đồ cấu hình có được tải vào Kubernetes hay không:

$ kubectl get configmap
NAME                 DATA   AGE
proxysql-configmap   1      45s

Triển khai Pod

Bây giờ chúng ta nên triển khai nhóm blog. Gửi công việc triển khai tới Kubernetes:

$ kubectl create -f blog-deployment.yml

Xác minh trạng thái nhóm:

$ kubectl get pods
NAME                           READY   STATUS              RESTARTS   AGE
blog-54755cbcb5-t4cb7          2/2     Running             0          100s

Nó phải hiển thị 2/2 dưới cột ĐÃ SN SÀNG, cho biết có hai vùng chứa đang chạy bên trong nhóm. Sử dụng cờ tùy chọn -c để kiểm tra các vùng chứa Wordpress và ProxySQL bên trong nhóm blog:

$ kubectl logs blog-54755cbcb5-t4cb7 -c wordpress
$ kubectl logs blog-54755cbcb5-t4cb7 -c proxysql

Từ nhật ký vùng chứa ProxySQL, bạn sẽ thấy các dòng sau:

2018-10-20 08:57:14 [INFO] Dumping current MySQL Servers structures for hostgroup ALL
HID: 10 , address: 192.168.55.171 , port: 3306 , weight: 1 , status: ONLINE , max_connections: 100 , max_replication_lag: 0 , use_ssl: 0 , max_latency_ms: 0 , comment:
HID: 10 , address: 192.168.55.172 , port: 3306 , weight: 1 , status: OFFLINE_HARD , max_connections: 100 , max_replication_lag: 0 , use_ssl: 0 , max_latency_ms: 0 , comment:
HID: 20 , address: 192.168.55.171 , port: 3306 , weight: 1 , status: ONLINE , max_connections: 100 , max_replication_lag: 0 , use_ssl: 0 , max_latency_ms: 0 , comment:
HID: 20 , address: 192.168.55.172 , port: 3306 , weight: 1 , status: ONLINE , max_connections: 100 , max_replication_lag: 0 , use_ssl: 0 , max_latency_ms: 0 , comment:

HID 10 (nhóm máy chủ của người viết) chỉ được có một nút ONLINE (cho biết một nút chính duy nhất) và máy chủ còn lại ít nhất phải ở trạng thái OFFLINE_HARD. Đối với HID 20, nó được mong đợi là ONLINE cho tất cả các nút (chỉ ra nhiều bản sao đọc).

Để nhận tóm tắt về việc triển khai, hãy sử dụng cờ mô tả:

$ kubectl describe deployments blog

Blog của chúng tôi hiện đang chạy, tuy nhiên chúng tôi không thể truy cập nó từ bên ngoài mạng Kubernetes mà không định cấu hình dịch vụ, như được giải thích trong phần tiếp theo.

Tạo dịch vụ blog

Bước cuối cùng là tạo đính kèm một dịch vụ vào nhóm của chúng tôi. Điều này để đảm bảo rằng nhóm blog Wordpress của chúng tôi có thể truy cập được từ thế giới bên ngoài. Tạo một tệp có tên là blog-svc.yml và dán dòng sau:

apiVersion: v1
kind: Service
metadata:
  name: blog
  labels:
    app: blog
    tier: frontend
spec:
  type: NodePort
  ports:
  - name: blog
    nodePort: 30080
    port: 80
  selector:
    app: blog
    tier: frontend

Tạo dịch vụ:

$ kubectl create -f blog-svc.yml

Xác minh xem dịch vụ có được tạo đúng cách hay không:

[email protected]:~/proxysql-blog# kubectl get svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
blog         NodePort    10.96.140.37   <none>        80:30080/TCP   26s
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP        43h

Cổng 80 do nhóm blog xuất bản hiện được ánh xạ với thế giới bên ngoài qua cổng 30080. Chúng tôi có thể truy cập bài đăng trên blog của mình tại http:// {any_kubernetes_host}:30080 / và sẽ được chuyển hướng đến trang cài đặt Wordpress. Nếu chúng tôi tiến hành cài đặt, nó sẽ bỏ qua phần kết nối cơ sở dữ liệu và hiển thị trực tiếp trang này:

Nó chỉ ra rằng cấu hình MySQL và ProxySQL của chúng tôi được định cấu hình chính xác bên trong tệp wp-config.php. Nếu không, bạn sẽ được chuyển hướng đến trang cấu hình cơ sở dữ liệu.

Việc triển khai của chúng tôi hiện đã hoàn tất.

Quản lý Vùng chứa ProxySQL bên trong Pod

Chuyển đổi dự phòng và khôi phục dự kiến sẽ được Kubernetes xử lý tự động. Ví dụ:nếu Kubernetes worker gặp sự cố, nhóm sẽ được tạo lại trong nút có sẵn tiếp theo sau --pod-eviction-timeout (mặc định là 5 phút). Nếu vùng chứa gặp sự cố hoặc bị chết, Kubernetes sẽ thay thế nó gần như ngay lập tức.

Một số tác vụ quản lý chung dự kiến sẽ khác khi chạy trong Kubernetes, như được hiển thị trong các phần tiếp theo.

Mở rộng quy mô lên và xuống

Trong cấu hình trên, chúng tôi đã triển khai một bản sao trong quá trình triển khai của mình. Để mở rộng quy mô, chỉ cần thay đổi spec.replicas giá trị tương ứng bằng cách sử dụng lệnh chỉnh sửa kubectl:

$ kubectl edit deployment blog

Nó sẽ mở ra định nghĩa triển khai trong tệp văn bản mặc định và chỉ cần thay đổi spec.replicas giá trị cao hơn, ví dụ:"bản sao:3". Sau đó, lưu tệp và ngay lập tức kiểm tra trạng thái phát hành bằng cách sử dụng lệnh sau:

$ kubectl rollout status deployment blog
Waiting for deployment "blog" rollout to finish: 1 of 3 updated replicas are available...
Waiting for deployment "blog" rollout to finish: 2 of 3 updated replicas are available...
deployment "blog" successfully rolled out

Tại thời điểm này, chúng tôi có ba nhóm blog (Wordpress + ProxySQL) đang chạy liên tục trong Kubernetes:

$ kubectl get pods
NAME                             READY   STATUS              RESTARTS   AGE
blog-54755cbcb5-6fnqn            2/2     Running             0          11m
blog-54755cbcb5-cwpdj            2/2     Running             0          11m
blog-54755cbcb5-jxtvc            2/2     Running             0          22m

Tại thời điểm này, kiến trúc của chúng tôi trông giống như sau:

Lưu ý rằng nó có thể yêu cầu nhiều tùy chỉnh hơn so với cấu hình hiện tại của chúng tôi để chạy Wordpress trơn tru trong môi trường sản xuất quy mô ngang (hãy nghĩ về nội dung tĩnh, quản lý phiên và những thứ khác). Những điều đó thực sự nằm ngoài phạm vi của bài đăng blog này.

Quy trình thu nhỏ cũng tương tự.

Quản lý cấu hình

Quản lý cấu hình rất quan trọng trong ProxySQL. Đây là nơi điều kỳ diệu xảy ra khi bạn có thể xác định bộ quy tắc truy vấn của riêng mình để thực hiện bộ nhớ đệm truy vấn, tường lửa và viết lại. Trái ngược với thông lệ phổ biến, nơi ProxySQL sẽ được định cấu hình thông qua Bảng điều khiển dành cho quản trị viên và đẩy vào tính ổn định bằng cách sử dụng "SAVE .. TO DISK", chúng tôi sẽ chỉ gắn bó với các tệp cấu hình để làm cho mọi thứ trở nên linh hoạt hơn trong Kubernetes. Đó là lý do chúng tôi sử dụng ConfigMaps.

Vì chúng tôi đang dựa vào cấu hình tập trung được Kubernetes ConfigMaps lưu trữ, nên có một số cách để thực hiện thay đổi cấu hình. Đầu tiên, bằng cách sử dụng lệnh chỉnh sửa kubectl:

$ kubectl edit configmap proxysql-configmap

Nó sẽ mở cấu hình trong trình soạn thảo văn bản mặc định và bạn có thể trực tiếp thực hiện các thay đổi đối với nó và lưu tệp văn bản sau khi hoàn tất. Nếu không, việc tạo lại các sơ đồ cấu hình cũng nên làm:

$ vi proxysql.cnf # edit the configuration first
$ kubectl delete configmap proxysql-configmap
$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf

Sau khi cấu hình được đẩy vào ConfigMap, hãy khởi động lại nhóm hoặc vùng chứa như được hiển thị trong phần Kiểm soát dịch vụ. Định cấu hình vùng chứa thông qua giao diện quản trị ProxySQL (cổng 6032) sẽ không làm cho nó hoạt động ổn định sau khi lập lịch lại pod bởi Kubernetes.

Kiểm soát dịch vụ

Vì hai vùng chứa bên trong một nhóm được ghép nối chặt chẽ, nên cách tốt nhất để áp dụng các thay đổi cấu hình ProxySQL là buộc Kubernetes thực hiện thay thế nhóm. Hãy xem xét chúng tôi hiện có ba nhóm blog sau khi chúng tôi mở rộng quy mô:

$ kubectl get pods
NAME                             READY   STATUS              RESTARTS   AGE
blog-54755cbcb5-6fnqn            2/2     Running             0          31m
blog-54755cbcb5-cwpdj            2/2     Running             0          31m
blog-54755cbcb5-jxtvc            2/2     Running             1          22m

Sử dụng lệnh sau để thay thế từng nhóm một:

$ kubectl get pod blog-54755cbcb5-6fnqn -n default -o yaml | kubectl replace --force -f -
pod "blog-54755cbcb5-6fnqn" deleted
pod/blog-54755cbcb5-6fnqn

Sau đó, xác minh với những điều sau:

$ kubectl get pods
NAME                             READY   STATUS              RESTARTS   AGE
blog-54755cbcb5-6fnqn            2/2     Running             0          31m
blog-54755cbcb5-cwpdj            2/2     Running             0          31m
blog-54755cbcb5-qs6jm            2/2     Running             1          2m26s

Bạn sẽ nhận thấy nhóm gần đây nhất đã được khởi động lại bằng cách nhìn vào cột AGE và RESTART, nó có một tên nhóm khác. Lặp lại các bước tương tự cho các nhóm còn lại. Nếu không, bạn cũng có thể sử dụng lệnh "docker kill" để giết vùng chứa ProxySQL theo cách thủ công bên trong nút công nhân Kubernetes. Ví dụ:

(kube-worker)$ docker kill $(docker ps | grep -i proxysql_blog | awk {'print $1'})

Kubernetes sau đó sẽ thay thế vùng chứa ProxySQL đã bị hủy bằng một vùng chứa mới.

Giám sát

Sử dụng lệnh kubectl exec để thực thi câu lệnh SQL thông qua máy khách mysql. Ví dụ:để theo dõi việc phân loại truy vấn:

$ kubectl exec -it blog-54755cbcb5-29hqt -c proxysql -- mysql -uadmin -p -h127.0.0.1 -P6032
mysql> SELECT * FROM stats_mysql_query_digest;

Hoặc với một lớp lót:

$ kubectl exec -it blog-54755cbcb5-29hqt -c proxysql -- mysql -uadmin -p -h127.0.0.1 -P6032 -e 'SELECT * FROM stats_mysql_query_digest'

Bằng cách thay đổi câu lệnh SQL, bạn có thể giám sát các thành phần ProxySQL khác hoặc thực hiện bất kỳ tác vụ quản trị nào thông qua Bảng điều khiển dành cho quản trị viên này. Một lần nữa, nó sẽ chỉ tồn tại trong suốt thời gian tồn tại của vùng chứa ProxySQL và sẽ không tồn tại nếu nhóm được lên lịch lại.

Lời kết

ProxySQL giữ một vai trò quan trọng nếu bạn muốn mở rộng vùng chứa ứng dụng của mình và có một cách thông minh để truy cập vào phần phụ trợ cơ sở dữ liệu phân tán. Có một số cách để triển khai ProxySQL trên Kubernetes để hỗ trợ sự phát triển ứng dụng của chúng tôi khi chạy trên quy mô lớn. Bài đăng trên blog này chỉ đề cập đến một trong số chúng.

Trong một bài đăng blog sắp tới, chúng ta sẽ xem xét cách chạy ProxySQL theo phương pháp tập trung bằng cách sử dụng nó như một dịch vụ Kubernetes.