Khi chạy các cụm cơ sở dữ liệu phân tán, việc đặt chúng trước các bộ cân bằng tải là điều khá phổ biến. Những ưu điểm rất rõ ràng - cân bằng tải, chuyển đổi dự phòng kết nối và tách lớp ứng dụng khỏi các cấu trúc liên kết cơ sở dữ liệu bên dưới. Để cân bằng tải thông minh hơn, một proxy nhận biết cơ sở dữ liệu như ProxySQL hoặc MaxScale sẽ là cách để đi. Trong blog trước của chúng tôi, chúng tôi đã hướng dẫn bạn cách chạy ProxySQL như một vùng chứa trợ giúp trong Kubernetes. Trong bài đăng trên blog này, chúng tôi sẽ hướng dẫn bạn cách triển khai ProxySQL dưới dạng dịch vụ Kubernetes. Chúng tôi sẽ sử dụng Wordpress làm ứng dụng mẫu và phần phụ trợ cơ sở dữ liệu đang chạy trên Bản sao MySQL hai nút được triển khai bằng ClusterControl. Sơ đồ sau minh họa cơ sở hạ tầng của chúng tôi:
Vì chúng tôi sẽ triển khai một thiết lập tương tự như trong bài đăng trên blog trước này, chúng tôi mong đợi sự trùng lặp trong một số phần của bài đăng trên blog để giữ cho bài đăng dễ đọc hơn.
ProxySQL trên Kubernetes
Hãy bắt đầu với một chút tóm tắt. Thiết kế một 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ùng chứa cơ sở dữ liệu cũng như vai trò của chính ProxySQL. 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)
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:
Bài đăng trên blog này sẽ đề cập đến cấu hình đầu tiên - chạy ProxySQL như một dịch vụ Kubernetes. Cấu hình thứ hai đã được đề cập ở đây. Ngược lại với cách tiếp cận vùng chứa trợ giúp, việc chạy như một dịch vụ làm cho các nhóm ProxySQL sống độc lập với các ứng dụng và có thể dễ dàng mở rộng quy mô và nhóm lại với nhau với sự trợ giúp của Kubernetes ConfigMap. Đây chắc chắn là một cách tiếp cận phân cụm khác với hỗ trợ phân cụm gốc ProxySQL dựa trên tổng kiểm tra cấu hình trên các phiên bản ProxySQL (còn gọi là proxysql_servers). Hãy xem bài đăng trên blog này nếu bạn muốn tìm hiểu về phân cụm ProxySQL được thực hiện dễ dàng với ClusterControl.
Trong Kubernetes, hệ thống cấu hình nhiều lớp của ProxySQL làm cho việc phân cụm nhóm có thể thực hiện được với ConfigMap. Tuy nhiên, có một số thiếu sót và cách giải quyết để làm cho nó hoạt động trơn tru như những gì tính năng phân cụm gốc của ProxySQL thực hiện. Hiện tại, báo hiệu một nhóm khi cập nhật ConfigMap là một tính năng đang hoạt động. Chúng tôi sẽ đề cập đến chủ đề này một cách chi tiết hơn trong một bài đăng blog sắp tới.
Về cơ bản, chúng ta cần tạo các nhóm ProxySQL và đính kèm một dịch vụ Kubernetes để các nhóm khác truy cập trong mạng Kubernetes hoặc bên ngoài. Các ứng dụng sau đó sẽ kết nối với dịch vụ ProxySQL thông qua mạng TCP / IP trên các cổng được cấu hình. Mặc định là 6033 cho các kết nối cân bằng tải MySQL và 6032 cho bảng điều khiển quản trị ProxySQL. Với nhiều hơn một bản sao, các kết nối đến nhóm sẽ được cân bằng tải tự động bởi thành phần kube-proxy Kubernetes chạy trên mọi nút Kubernetes.
ProxySQL dưới dạng Dịch vụ Kubernetes
Trong thiết lập này, chúng tôi chạy cả ProxySQL và Wordpress dưới dạng nhóm và dịch vụ. 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, chúng tôi sẽ triển khai hai nhóm và dịch vụ - "wordpress" và "proxysql". Chúng tôi sẽ hợp nhất khai báo Triển khai và Dịch vụ trong một tệp YAML cho mỗi ứng dụng và quản lý chúng như một đơn vị. Để 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.
Triển khai ProxySQL như một dịch vụ mang lại một số điều tốt so với phương pháp tiếp cận vùng chứa trợ giúp:
- Sử dụng phương pháp Kubernetes ConfigMap, ProxySQL có thể được phân nhóm với cấu hình bất biến.
- Kubernetes xử lý khôi phục ProxySQL và tự động cân bằng kết nối với các phiên bản.
- Một điểm cuối có triển khai địa chỉ IP ảo Kubernetes được gọi là ClusterIP.
- Cấp proxy ngược tập trung không có kiến trúc được chia sẻ.
- Có thể được sử dụng với các ứng dụng bên ngoài bên ngoài Kubernetes.
Chúng tôi sẽ bắt đầu triển khai dưới dạng hai bản sao cho ProxySQL và ba bản cho Wordpress để chứng minh khả năng chạy ở quy mô và khả năng cân bằng tải mà Kubernetes cung cấp.
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;ProxySQL Pod và Định nghĩa dịch vụ
Việc tiếp theo là chuẩn bị triển khai ProxySQL của chúng tôi. Tạo tệp có tên proxysql-rs-svc.yml và thêm các dòng sau:
apiVersion: v1
kind: Deployment
metadata:
name: proxysql
labels:
app: proxysql
spec:
replicas: 2
selector:
matchLabels:
app: proxysql
tier: frontend
strategy:
type: RollingUpdate
template:
metadata:
labels:
app: proxysql
tier: frontend
spec:
restartPolicy: Always
containers:
- image: severalnines/proxysql:1.4.12
name: proxysql
volumeMounts:
- name: proxysql-config
mountPath: /etc/proxysql.cnf
subPath: proxysql.cnf
ports:
- containerPort: 6033
name: proxysql-mysql
- containerPort: 6032
name: proxysql-admin
volumes:
- name: proxysql-config
configMap:
name: proxysql-configmap
---
apiVersion: v1
kind: Service
metadata:
name: proxysql
labels:
app: proxysql
tier: frontend
spec:
type: NodePort
ports:
- nodePort: 30033
port: 6033
name: proxysql-mysql
- nodePort: 30032
port: 6032
name: proxysql-admin
selector:
app: proxysql
tier: frontendHãy xem những định nghĩa đó là gì. YAML bao gồm hai tài nguyên được kết hợp trong một tệp, được phân tách bằng dấu phân cách "---". Tài nguyên đầu tiên là Triển khai, mà chúng tôi xác định thông số kỹ thuật sau:
spec:
replicas: 2
selector:
matchLabels:
app: proxysql
tier: frontend
strategy:
type: RollingUpdateĐiều trên có nghĩa là chúng tôi muốn triển khai hai nhóm ProxySQL dưới dạng ReplicaSet khớp với các vùng chứa có nhãn "app =proxysql, tier =frontend". Chiến lược triển khai chỉ định chiến lược được sử dụng để thay thế các nhóm cũ bằng các nhóm mới. Trong lần triển khai này, chúng tôi đã chọn RollingUpdate có nghĩa là các nhóm sẽ được cập nhật theo kiểu cập nhật liên tục, từng nhóm một.
Phần tiếp theo là mẫu của vùng chứa:
- image: severalnines/proxysql:1.4.12
name: proxysql
volumeMounts:
- name: proxysql-config
mountPath: /etc/proxysql.cnf
subPath: proxysql.cnf
ports:
- containerPort: 6033
name: proxysql-mysql
- containerPort: 6032
name: proxysql-admin
volumes:
- name: proxysql-config
configMap:
name: proxysql-configmapTrong spec.templates.spec.containers. * , 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. Các nhóm đang chạy sẽ xuất bản hai cổng - 6033 và 6032. Chúng tôi cũng xác định phần "khối lượng", nơi chúng tôi hướng dẫn Kubernetes gắn kết Bản đồ cấu hình như một ổ đĩa bên trong các nhóm ProxySQL để được gắn kết bằng khối lượng.
Tài nguyên thứ hai là dịch vụ. Dịch vụ Kubernetes là một lớp trừu tượng xác định tập hợp lôgic của các nhóm và một chính sách để truy cập chúng. Trong phần này, chúng tôi xác định những điều sau:
apiVersion: v1
kind: Service
metadata:
name: proxysql
labels:
app: proxysql
tier: frontend
spec:
type: NodePort
ports:
- nodePort: 30033
port: 6033
name: proxysql-mysql
- nodePort: 30032
port: 6032
name: proxysql-admin
selector:
app: proxysql
tier: frontendTrong trường hợp này, chúng tôi muốn ProxySQL của chúng tôi được truy cập từ mạng bên ngoài, do đó kiểu NodePort là kiểu được chọn. Điều này sẽ xuất bản nodePort trên mọi nút Kubernetes trong cụm. Phạm vi các cổng hợp lệ cho tài nguyên NodePort là 30000-32767. Chúng tôi đã chọn cổng 30033 cho các kết nối cân bằng tải MySQL được ánh xạ tới cổng 6033 của nhóm ProxySQL và cổng 30032 cho cổng Quản trị ProxySQL được ánh xạ tới 6032.
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ị tài nguyên Kubernetes sau trước khi có thể bắt đầu triển khai nhóm "proxysql":
- ConfigMap - Để lưu trữ tệp cấu hình ProxySQL dưới dạng một ổ đĩa để nó có thể được gắn vào nhiều nhóm và có thể được đếm lại nếu nhóm đó đang được lên lịch lại cho nút Kubernetes khác.
Chuẩn bị Bản đồ cấu hình cho ProxySQL
Tương tự như bài đăng trên blog trước, chúng tôi sẽ sử dụng phương pháp ConfigMap để tách tệp cấu hình khỏi vùng chứa và cũng cho mục đích khả năng mở rộng. Lưu ý rằng trong thiết lập này, chúng tôi coi cấu hình ProxySQL của chúng tôi là bất biến.
Trước tiên, hãy tạo tệp cấu hình ProxySQL, proxysql.cnf và thêm các dòng sau:
datadir="/var/lib/proxysql"
admin_variables=
{
admin_credentials="proxysql-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_replication_hostgroups =
(
{ writer_hostgroup=10, reader_hostgroup=20, comment="MySQL Replication 5.7" }
)
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
}
)Hãy chú ý đến admin_variables.admin_credentials biến mà chúng tôi đã sử dụng người dùng không phải mặc định là "proxysql-admin". ProxySQL chỉ dành riêng người dùng "quản trị viên" mặc định cho kết nối cục bộ qua máy chủ cục bộ. Do đó, chúng tôi phải sử dụng những người dùng khác để truy cập phiên bản ProxySQL từ xa. Nếu không, bạn sẽ gặp lỗi sau:
ERROR 1040 (42000): User 'admin' can only connect locallyCấu hình ProxySQL của chúng tôi dựa trên hai máy chủ cơ sở dữ liệu của chúng tôi đ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 createdXá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 45sWordpress Pod và Định nghĩa dịch vụ
Bây giờ, hãy dán các dòng sau vào một tệp có tên là wordpress-rs-svc.yml trên máy chủ nơi kubectl được định cấu hình:
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress
labels:
app: wordpress
spec:
replicas: 3
selector:
matchLabels:
app: wordpress
tier: frontend
strategy:
type: RollingUpdate
template:
metadata:
labels:
app: wordpress
tier: frontend
spec:
restartPolicy: Always
containers:
- image: wordpress:4.9-apache
name: wordpress
env:
- name: WORDPRESS_DB_HOST
value: proxysql:6033 # proxysql.default.svc.cluster.local:6033
- name: WORDPRESS_DB_USER
value: wordpress
- name: WORDPRESS_DB_DATABASE
value: wordpress
- name: WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-pass
key: password
ports:
- containerPort: 80
name: wordpress
---
apiVersion: v1
kind: Service
metadata:
name: wordpress
labels:
app: wordpress
tier: frontend
spec:
type: NodePort
ports:
- name: wordpress
nodePort: 30088
port: 80
selector:
app: wordpress
tier: frontendTương tự như định nghĩa ProxySQL của chúng tôi, YAML bao gồm hai tài nguyên, được phân tách bằng dấu phân cách "---" được kết hợp trong một tệp. Đầu tiên là tài nguyên Triển khai, tài nguyên này sẽ được triển khai dưới dạng ReplicaSet, như được hiển thị trong phần "spec. *":
spec:
replicas: 3
selector:
matchLabels:
app: wordpress
tier: frontend
strategy:
type: RollingUpdatePhần này cung cấp thông số kỹ thuật Triển khai - 3 nhóm để bắt đầu khớp với nhãn "app =wordpress, tier =backend". Chiến lược triển khai là RollingUpdate có nghĩa là cách Kubernetes sẽ thay thế nhóm này bằng cách sử dụng thời trang cập nhật liên tục, giống với việc triển khai ProxySQL của chúng tôi.
Phần tiếp theo là phần "spec.template.spec. *":
restartPolicy: Always
containers:
- image: wordpress:4.9-apache
name: wordpress
env:
- name: WORDPRESS_DB_HOST
value: proxysql:6033
- 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
Trong phần này, chúng tôi đang 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". Vùng chứa sẽ được khởi động lại mỗi khi nó gặp sự cố, bất kể trạng thái như thế nào. 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 MySQL. Vì chúng tôi đang sử dụng ProxySQL làm dịch vụ nên tên dịch vụ sẽ là giá trị của metadata.name là "proxysql". ProxySQL lắng nghe trên cổng 6033 cho các kết nối cân bằng tải MySQL trong khi bảng điều khiển quản trị ProxySQL trên 6032.
- WORDPRESS_DB_USER - Chỉ định người dùng cơ sở dữ liệu wordpress đã được tạo trong phần "Chuẩn bị cơ sở dữ liệu".
- 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 pod 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. Chúng tôi sẽ sử dụng các tài nguyên PersentlyVolume và PersentlyVolumeClaim cho mục đích này như được hiển thị trong phần "Chuẩn bị lưu trữ liên tục cho Wordpress".
Sau dòng ngắt "---", chúng tôi xác định một tài nguyên khác được gọi là Dịch vụ:
apiVersion: v1
kind: Service
metadata:
name: wordpress
labels:
app: wordpress
tier: frontend
spec:
type: NodePort
ports:
- name: wordpress
nodePort: 30088
port: 80
selector:
app: wordpress
tier: frontendTrong cấu hình này, chúng tôi muốn Kubernetes tạo một dịch vụ có tên "wordpress", lắng nghe trên cổng 30088 trên tất cả các nút (còn gọi là NodePort) với mạng bên ngoài và chuyển tiếp nó tới cổng 80 trên tất cả các nhóm có nhãn "app =wordpress, tier =giao diện người dùng ".
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 và dịch vụ "wordpress":
- 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.
Chuẩn bị lưu trữ liên tục cho Wordpress
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 (như được hiển thị trong sơ đồ kiến trúc đầu tiên) và chúng tôi đã định cấu hình nó để cho phép tất cả các nút Kubernetes có 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/CentOSNgoà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/wordpressSau đó, 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: wordpress
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: wordpress
tier: frontendTrong định nghĩa trên, chúng tôi đang yêu cầu 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.ymlXá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 22hChuẩn bị bí mật cho Wordpress
Tạo bí mật để vùng chứa Wordpress sử dụng 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=passw0rdXá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 7h12mTriển khai ProxySQL và Wordpress
Cuối cùng, chúng ta có thể bắt đầu triển khai. Triển khai ProxySQL trước, sau đó là Wordpress:
$ kubectl create -f proxysql-rs-svc.yml
$ kubectl create -f wordpress-rs-svc.ymlSau đó, chúng tôi có thể liệt kê tất cả các nhóm và dịch vụ đã được tạo trong cấp "giao diện người dùng":
$ kubectl get pods,services -l tier=frontend -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
pod/proxysql-95b8d8446-qfbf2 1/1 Running 0 12m 10.36.0.2 kube2.local <none>
pod/proxysql-95b8d8446-vljlr 1/1 Running 0 12m 10.44.0.6 kube3.local <none>
pod/wordpress-59489d57b9-4dzvk 1/1 Running 0 37m 10.36.0.1 kube2.local <none>
pod/wordpress-59489d57b9-7d2jb 1/1 Running 0 30m 10.44.0.4 kube3.local <none>
pod/wordpress-59489d57b9-gw4p9 1/1 Running 0 30m 10.36.0.3 kube2.local <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/proxysql NodePort 10.108.195.54 <none> 6033:30033/TCP,6032:30032/TCP 10m app=proxysql,tier=frontend
service/wordpress NodePort 10.109.144.234 <none> 80:30088/TCP 37m app=wordpress,tier=frontend
kube2.local <none>Kết quả ở trên xác minh kiến trúc triển khai của chúng tôi, nơi chúng tôi hiện đang có ba nhóm Wordpress, được hiển thị trên cổng 30088 công khai cũng như phiên bản ProxySQL của chúng tôi được hiển thị trên cổng 30033 và 30032 bên ngoài cộng với 6033 và 6032 trong nội bộ.
Tại thời điểm này, kiến trúc của chúng tôi trông giống như sau:
Cổng 80 do nhóm Wordpress xuất bản hiện được ánh xạ với thế giới bên ngoài qua cổng 30088. 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}:30088 / 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.
ProxySQL Pods và Quản lý dịch vụ
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 nhân viên Kubernetes gặp sự cố, nhóm sẽ được tạo lại trong nút khả dụng 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.
Kết nối với ProxySQL
Trong khi ProxySQL được hiển thị bên ngoài trên cổng 30033 (MySQL) và 30032 (Quản trị), nó cũng có thể truy cập nội bộ thông qua các cổng đã xuất bản, lần lượt là 6033 và 6032. Do đó, để truy cập các phiên bản ProxySQL trong mạng Kubernetes, hãy sử dụng CLUSTER-IP hoặc tên dịch vụ "proxysql" làm giá trị máy chủ. Ví dụ:trong Wordpress pod, bạn có thể truy cập bảng điều khiển quản trị ProxySQL bằng cách sử dụng lệnh sau:
$ mysql -uproxysql-admin -p -hproxysql -P6032Nếu bạn muốn kết nối bên ngoài, hãy sử dụng cổng được xác định theo giá trị nodePort mà anh ta phục vụ YAML và chọn bất kỳ nút nào trong số các nút Kubernetes làm giá trị máy chủ:
$ mysql -uproxysql-admin -p -hkube3.local -P30032Điều tương tự cũng áp dụng cho kết nối cân bằng tải MySQL trên cổng 30033 (bên ngoài) và 6033 (bên trong).
Mở rộng quy mô lên và xuống
Mở rộng quy mô thật dễ dàng với Kubernetes:
$ kubectl scale deployment proxysql --replicas=5
deployment.extensions/proxysql scaledXác minh trạng thái phát hành:
$ kubectl rollout status deployment proxysql
deployment "proxysql" successfully rolled outViệc thu nhỏ quy mô cũng diễn ra tương tự. Ở đây chúng tôi muốn hoàn nguyên từ 5 đến 2 bản sao:
$ kubectl scale deployment proxysql --replicas=2
deployment.extensions/proxysql scaledChúng tôi cũng có thể xem xét các sự kiện triển khai cho ProxySQL để có bức tranh tốt hơn về những gì đã xảy ra cho việc triển khai này bằng cách sử dụng tùy chọn "description":
$ kubectl describe deployment proxysql
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 20m deployment-controller Scaled up replica set proxysql-769895fbf7 to 1
Normal ScalingReplicaSet 20m deployment-controller Scaled down replica set proxysql-95b8d8446 to 1
Normal ScalingReplicaSet 20m deployment-controller Scaled up replica set proxysql-769895fbf7 to 2
Normal ScalingReplicaSet 20m deployment-controller Scaled down replica set proxysql-95b8d8446 to 0
Normal ScalingReplicaSet 7m10s deployment-controller Scaled up replica set proxysql-6c55f647cb to 1
Normal ScalingReplicaSet 7m deployment-controller Scaled down replica set proxysql-769895fbf7 to 1
Normal ScalingReplicaSet 7m deployment-controller Scaled up replica set proxysql-6c55f647cb to 2
Normal ScalingReplicaSet 6m53s deployment-controller Scaled down replica set proxysql-769895fbf7 to 0
Normal ScalingReplicaSet 54s deployment-controller Scaled up replica set proxysql-6c55f647cb to 5
Normal ScalingReplicaSet 21s deployment-controller Scaled down replica set proxysql-6c55f647cb to 2Các kết nối với nhóm sẽ được Kubernetes cân bằng tải tự động.
Thay đổi cấu hình
Một cách để thực hiện các thay đổi cấu hình trên các nhóm ProxySQL của chúng tôi là tạo phiên bản cho cấu hình của chúng tôi bằng tên ConfigMap khác. Trước hết, hãy sửa đổi tệp cấu hình của chúng tôi trực tiếp thông qua trình soạn thảo văn bản yêu thích của bạn:
$ vim /root/proxysql.cnfSau đó, tải nó vào Kubernetes ConfigMap với một tên khác. Trong ví dụ này, chúng tôi thêm "-v2" vào tên tài nguyên:
$ kubectl create configmap proxysql-configmap-v2 --from-file=proxysql.cnfXác minh xem Bản đồ cấu hình có được tải đúng không:
$ kubectl get configmap
NAME DATA AGE
proxysql-configmap 1 3d15h
proxysql-configmap-v2 1 19mMở tệp triển khai ProxySQL, proxysql-rs-svc.yml và thay đổi dòng sau trong phần Bản đồ cấu hình thành phiên bản mới:
volumes:
- name: proxysql-config
configMap:
name: proxysql-configmap-v2 #change this lineSau đó, áp dụng các thay đổi cho việc triển khai ProxySQL của chúng tôi:
$ kubectl apply -f proxysql-rs-svc.yml
deployment.apps/proxysql configured
service/proxysql configuredXác minh việc phát hành bằng cách sử dụng xem sự kiện ReplicaSet sử dụng cờ "mô tả":
$ kubectl describe proxysql
...
Pod Template:
Labels: app=proxysql
tier=frontend
Containers:
proxysql:
Image: severalnines/proxysql:1.4.12
Ports: 6033/TCP, 6032/TCP
Host Ports: 0/TCP, 0/TCP
Environment: <none>
Mounts:
/etc/proxysql.cnf from proxysql-config (rw)
Volumes:
proxysql-config:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: proxysql-configmap-v2
Optional: false
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: proxysql-769895fbf7 (2/2 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 53s deployment-controller Scaled up replica set proxysql-769895fbf7 to 1
Normal ScalingReplicaSet 46s deployment-controller Scaled down replica set proxysql-95b8d8446 to 1
Normal ScalingReplicaSet 46s deployment-controller Scaled up replica set proxysql-769895fbf7 to 2
Normal ScalingReplicaSet 41s deployment-controller Scaled down replica set proxysql-95b8d8446 to 0Hãy chú ý đến phần "Volumes" với tên ConfigMap mới. Bạn cũng có thể xem các sự kiện triển khai ở cuối đầu ra. Tại thời điểm này, cấu hình mới của chúng tôi đã được tải vào tất cả các nhóm ProxySQL, nơi Kubernetes thu nhỏ ProxySQL ReplicaSet xuống 0 (tuân theo chiến lược RollingUpdate) và đưa chúng trở lại trạng thái mong muốn của 2 bản sao.
Lời kết
Cho đến thời điểm này, chúng tôi đã đề cập đến cách tiếp cận triển khai có thể có cho ProxySQL trong Kubernetes. Chạy ProxySQL với sự trợ giúp của Kubernetes ConfigMap mở ra một khả năng mới về phân cụm ProxySQL, nơi nó hơi khác so với hỗ trợ phân cụm gốc được tích hợp bên trong ProxySQL.
Trong bài đăng trên blog sắp tới, chúng ta sẽ khám phá ProxySQL Clustering sử dụng Kubernetes ConfigMap và cách thực hiện đúng cách. Hãy theo dõi!
