ProxySQL को Kubernetes Service के रूप में चलाना

वितरित डेटाबेस क्लस्टर चलाते समय, लोड बैलेंसर के साथ उनका सामना करना काफी आम है। लाभ स्पष्ट हैं - लोड संतुलन, कनेक्शन विफलता और अंतर्निहित डेटाबेस टोपोलॉजी से एप्लिकेशन टियर का डिकॉउलिंग। अधिक बुद्धिमान लोड संतुलन के लिए, ProxySQL या MaxScale जैसे डेटाबेस-जागरूक प्रॉक्सी जाने का रास्ता होगा। हमारे पिछले ब्लॉग में, हमने आपको दिखाया था कि कैसे Kubernetes में ProxySQL को हेल्पर कंटेनर के रूप में चलाया जाता है। इस ब्लॉग पोस्ट में, हम आपको दिखाएंगे कि ProxySQL को Kubernetes सेवा के रूप में कैसे परिनियोजित किया जाए। हम Wordpress को एक उदाहरण एप्लिकेशन के रूप में उपयोग करेंगे और डेटाबेस बैकएंड क्लस्टरकंट्रोल का उपयोग करके तैनात दो-नोड MySQL प्रतिकृति पर चल रहा है। निम्नलिखित आरेख हमारे बुनियादी ढांचे को दर्शाता है:

चूंकि हम इस पिछले ब्लॉग पोस्ट की तरह एक समान सेटअप परिनियोजित करने जा रहे हैं, इसलिए पोस्ट को अधिक पठनीय बनाए रखने के लिए ब्लॉग पोस्ट के कुछ हिस्सों में दोहराव की अपेक्षा करें।

कुबेरनेट्स पर प्रॉक्सीएसक्यूएल

आइए थोड़ा पुनर्कथन के साथ शुरू करें। ProxySQL आर्किटेक्चर को डिज़ाइन करना एक व्यक्तिपरक विषय है और यह एप्लिकेशन, डेटाबेस कंटेनरों के साथ-साथ ProxySQL की भूमिका पर अत्यधिक निर्भर है। आदर्श रूप से, हम ProxySQL को कुबेरनेट्स द्वारा प्रबंधित करने के लिए दो कॉन्फ़िगरेशन के साथ कॉन्फ़िगर कर सकते हैं:

ProxySQL एक Kubernetes सेवा के रूप में (केंद्रीकृत परिनियोजन)
ProxySQL पॉड में एक सहायक कंटेनर के रूप में (वितरित परिनियोजन)

निम्नलिखित आरेख को देखकर दोनों परिनियोजनों को आसानी से पहचाना जा सकता है:

यह ब्लॉग पोस्ट पहले कॉन्फ़िगरेशन को कवर करेगा - ProxySQL को Kubernetes सेवा के रूप में चला रहा है। दूसरा कॉन्फ़िगरेशन पहले से ही यहां कवर किया गया है। सहायक कंटेनर दृष्टिकोण के विपरीत, एक सेवा के रूप में चलने से प्रॉक्सीएसक्यूएल पॉड्स अनुप्रयोगों से स्वतंत्र रूप से रहते हैं और कुबेरनेट्स कॉन्फिग मैप की मदद से आसानी से स्केल और क्लस्टर किया जा सकता है। यह निश्चित रूप से ProxySQL देशी क्लस्टरिंग समर्थन की तुलना में एक अलग क्लस्टरिंग दृष्टिकोण है जो ProxySQL इंस्टेंस (a.k.a proxysql_servers) में कॉन्फ़िगरेशन चेकसम पर निर्भर करता है। यदि आप ProxySQL क्लस्टरिंग को ClusterControl के साथ आसान बनाना चाहते हैं, तो इस ब्लॉग पोस्ट को देखें।

Kubernetes में, ProxySQL का मल्टी-लेयर कॉन्फ़िगरेशन सिस्टम ConfigMap के साथ पॉड क्लस्टरिंग को संभव बनाता है। हालाँकि, इसे सुचारू रूप से काम करने के लिए कई कमियाँ और समाधान हैं जो ProxySQL की मूल क्लस्टरिंग सुविधा करती है। फिलहाल, कॉन्फिग मैप अपडेट पर पॉड को सिग्नल करना काम में एक विशेषता है। आगामी ब्लॉग पोस्ट में हम इस विषय को और अधिक विस्तार से कवर करेंगे।

मूल रूप से, हमें ProxySQL पॉड बनाने और Kubernetes नेटवर्क के भीतर या बाहरी रूप से अन्य पॉड्स द्वारा एक्सेस करने के लिए एक Kubernetes सेवा संलग्न करने की आवश्यकता है। तब अनुप्रयोग कॉन्फ़िगर किए गए पोर्ट पर TCP/IP नेटवर्किंग के माध्यम से ProxySQL सेवा से कनेक्ट होंगे। MySQL लोड-संतुलित कनेक्शन के लिए डिफ़ॉल्ट 6033 और ProxySQL व्यवस्थापन कंसोल के लिए 6032। एक से अधिक प्रतिकृति के साथ, प्रत्येक कुबेरनेट्स नोड पर चलने वाले कुबेरनेट्स क्यूब-प्रॉक्सी घटक द्वारा पॉड के कनेक्शन स्वचालित रूप से संतुलित लोड हो जाएंगे।

ProxySQL कुबेरनेट्स सेवा के रूप में

इस सेटअप में, हम ProxySQL और Wordpress दोनों को पॉड और सेवाओं के रूप में चलाते हैं। निम्न आरेख हमारे उच्च-स्तरीय आर्किटेक्चर को दर्शाता है:

इस सेटअप में, हम दो पॉड्स और सेवाओं को तैनात करेंगे - "वर्डप्रेस" और "प्रॉक्सीस्क्ल"। हम प्रति एप्लिकेशन एक YAML फ़ाइल में परिनियोजन और सेवा घोषणा को मर्ज करेंगे और उन्हें एक इकाई के रूप में प्रबंधित करेंगे। एप्लिकेशन कंटेनर की सामग्री को कई नोड्स में बनाए रखने के लिए, हमें क्लस्टर या दूरस्थ फ़ाइल सिस्टम का उपयोग करना होगा, जो इस मामले में एनएफएस है।

ProxySQL को एक सेवा के रूप में तैनात करने से सहायक कंटेनर दृष्टिकोण पर कुछ अच्छी चीजें आती हैं:

Kubernetes ConfigMap दृष्टिकोण का उपयोग करके, ProxySQL को अपरिवर्तनीय कॉन्फ़िगरेशन के साथ क्लस्टर किया जा सकता है।
कुबेरनेट्स प्रॉक्सीएसक्यूएल रिकवरी को संभालता है और कनेक्शन को इंस्टेंस से स्वचालित रूप से संतुलित करता है।
कुबेरनेट्स वर्चुअल आईपी एड्रेस कार्यान्वयन के साथ सिंगल एंडपॉइंट जिसे क्लस्टरआईपी कहा जाता है।
साझा कुछ भी नहीं वास्तुकला के साथ केंद्रीकृत रिवर्स प्रॉक्सी टियर।
कुबेरनेट्स के बाहर बाहरी अनुप्रयोगों के साथ प्रयोग किया जा सकता है।

हम कुबेरनेट्स द्वारा प्रदान की जाने वाली स्केल और लोड-बैलेंसिंग क्षमताओं पर चलने को प्रदर्शित करने के लिए प्रॉक्सीएसक्यूएल के लिए दो प्रतिकृतियों और वर्डप्रेस के लिए तीन प्रतिकृतियों के रूप में परिनियोजन शुरू करेंगे।

डेटाबेस तैयार करना

मास्टर पर वर्डप्रेस डेटाबेस और उपयोगकर्ता बनाएं और सही विशेषाधिकार के साथ असाइन करें:

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

साथ ही, ProxySQL मॉनिटरिंग यूजर बनाएं:

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

फिर, अनुदान तालिका पुनः लोड करें:

mysql-master> FLUSH PRIVILEGES;

ProxySQL पॉड और सेवा परिभाषा

अगला हमारा ProxySQL परिनियोजन तैयार करना है। proxysql-rs-svc.yml called नामक फ़ाइल बनाएं और निम्नलिखित पंक्तियाँ जोड़ें:

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: frontend

आइए देखें कि वे सभी परिभाषाएँ क्या हैं। YAML में एक फ़ाइल में संयुक्त दो संसाधन होते हैं, जिन्हें "---" सीमांकक द्वारा अलग किया जाता है। पहला संसाधन परिनियोजन है, जिसे हम निम्नलिखित विनिर्देश परिभाषित करते हैं:

spec:
  replicas: 2
  selector:
    matchLabels:
      app: proxysql
      tier: frontend
  strategy:
    type: RollingUpdate

उपरोक्त का अर्थ है कि हम दो प्रॉक्सीएसक्यूएल पॉड्स को एक रेप्लिकासेट के रूप में तैनात करना चाहते हैं जो "ऐप =प्रॉक्सीस्क्ल, टियर =फ्रंटएंड" लेबल वाले कंटेनरों से मेल खाता है। परिनियोजन रणनीति पुराने पॉड्स को नए से बदलने के लिए उपयोग की जाने वाली रणनीति को निर्दिष्ट करती है। इस परिनियोजन में, हमने RollingUpdate को चुना, जिसका अर्थ है कि पॉड्स को रोलिंग अपडेट फैशन में अपडेट किया जाएगा, एक समय में एक पॉड।

अगला भाग कंटेनर का टेम्प्लेट है:

      - 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

spec.templates.spec.containers.* . में अनुभाग में, हम Kubernetes को कई/proxysql का उपयोग करके ProxySQL परिनियोजित करने के लिए कह रहे हैं छवि संस्करण 1.4.12. हम यह भी चाहते हैं कि कुबेरनेट्स हमारी कस्टम, पूर्व-कॉन्फ़िगर कॉन्फ़िगरेशन फ़ाइल को माउंट करें और इसे कंटेनर के अंदर /etc/proxysql.cnf पर मैप करें। रनिंग पॉड दो पोर्ट - 6033 और 6032 प्रकाशित करेंगे। हम "वॉल्यूम" सेक्शन को भी परिभाषित करते हैं, जहां हम कुबेरनेट्स को प्रोक्सीएसक्यूएल पॉड्स के अंदर वॉल्यूम के रूप में कॉन्फिग मैप को माउंट करने का निर्देश देते हैं।

दूसरा संसाधन सेवा है। कुबेरनेट्स सेवा एक अमूर्त परत है जो पॉड्स के तार्किक सेट और एक नीति को परिभाषित करती है जिसके द्वारा उन्हें एक्सेस किया जा सकता है। इस खंड में, हम निम्नलिखित को परिभाषित करते हैं:

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: frontend

इस मामले में, हम चाहते हैं कि हमारे प्रॉक्सीएसक्यूएल को बाहरी नेटवर्क से एक्सेस किया जाए, इस प्रकार नोडपोर्ट प्रकार चुना गया प्रकार है। यह क्लस्टर में प्रत्येक कुबेरनेट्स नोड्स पर नोडपोर्ट प्रकाशित करेगा। NodePort संसाधन के लिए मान्य पोर्ट की सीमा 30000-32767 है। हमने MySQL-लोड बैलेंस्ड कनेक्शन के लिए पोर्ट 30033 को चुना है जिसे ProxySQL पॉड्स के पोर्ट 6033 में मैप किया गया है और ProxySQL एडमिनिस्ट्रेशन पोर्ट के लिए पोर्ट 30032 को 6032 में मैप किया गया है।

इसलिए, ऊपर हमारी YAML परिभाषा के आधार पर, हमें "proxysql" पॉड को परिनियोजित करने से पहले निम्नलिखित Kubernetes संसाधन तैयार करना होगा:

ConfigMap - ProxySQL कॉन्फ़िगरेशन फ़ाइल को वॉल्यूम के रूप में संग्रहीत करने के लिए ताकि इसे कई पॉड पर रखा जा सके और यदि पॉड को अन्य Kubernetes नोड में पुनर्निर्धारित किया जा रहा है तो इसे फिर से माउंट किया जा सकता है।

ProxySQL के लिए ConfigMap तैयार करना

पिछले ब्लॉग पोस्ट की तरह, हम कंटेनर से कॉन्फ़िगरेशन फ़ाइल को अलग करने के लिए और स्केलेबिलिटी उद्देश्य के लिए भी ConfigMap दृष्टिकोण का उपयोग करने जा रहे हैं। ध्यान दें कि इस सेटअप में, हम मानते हैं कि हमारा ProxySQL कॉन्फ़िगरेशन अपरिवर्तनीय है।

सबसे पहले, ProxySQL कॉन्फ़िगरेशन फ़ाइल बनाएँ, proxysql.cnf और निम्नलिखित पंक्तियाँ जोड़ें:

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
        }
)

admin_variables.admin_credentials . पर ध्यान दें वेरिएबल जहां हमने गैर-डिफ़ॉल्ट उपयोगकर्ता का उपयोग किया जो "proxysql-admin" है। ProxySQL स्थानीय कनेक्शन के लिए केवल लोकलहोस्ट के माध्यम से डिफ़ॉल्ट "व्यवस्थापक" उपयोगकर्ता को सुरक्षित रखता है। इसलिए, हमें प्रॉक्सीएसक्यूएल इंस्टेंस को दूरस्थ रूप से एक्सेस करने के लिए अन्य उपयोगकर्ताओं का उपयोग करना होगा। अन्यथा, आपको निम्न त्रुटि प्राप्त होगी:

ERROR 1040 (42000): User 'admin' can only connect locally

हमारा ProxySQL कॉन्फ़िगरेशन MySQL प्रतिकृति में चल रहे हमारे दो डेटाबेस सर्वरों पर आधारित है, जैसा कि क्लस्टरकंट्रोल से लिए गए निम्नलिखित टोपोलॉजी स्क्रीनशॉट में संक्षेप में दिया गया है:

"mysql_query_rules" खंड के तहत परिभाषित अनुसार, सभी लेखन को मास्टर नोड में जाना चाहिए, जबकि रीड्स को होस्टग्रुप 20 में अग्रेषित किया जाता है। यह पढ़ने/लिखने के बंटवारे का मूल है और हम उनका पूरी तरह से उपयोग करना चाहते हैं।

फिर, कॉन्फ़िगरेशन फ़ाइल को ConfigMap में आयात करें:

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

सत्यापित करें कि ConfigMap Kubernetes में लोड किया गया है:

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

वर्डप्रेस पॉड और सेवा परिभाषा

अब, निम्न पंक्तियों को wordpress-rs-svc.yml . नामक फ़ाइल में चिपकाएँ होस्ट पर जहां कुबेक्टल कॉन्फ़िगर किया गया है:

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: frontend

हमारी ProxySQL परिभाषा के समान, YAML में दो संसाधन होते हैं, जो एक फ़ाइल में संयुक्त "---" सीमांकक द्वारा अलग किए जाते हैं। पहला है डिप्लॉयमेंट रिसोर्स, जिसे रेप्लिकासेट के रूप में तैनात किया जाएगा, जैसा कि "spec.*" सेक्शन में दिखाया गया है:

spec:
  replicas: 3
  selector:
    matchLabels:
      app: wordpress
      tier: frontend
  strategy:
    type: RollingUpdate

यह खंड परिनियोजन विनिर्देश प्रदान करता है - शुरू करने के लिए 3 पॉड जो "ऐप =वर्डप्रेस, टियर =बैकएंड" लेबल से मेल खाते हैं। परिनियोजन रणनीति रोलिंगअपडेट है, जिसका अर्थ है कि कुबेरनेट्स जिस तरह से पॉड को प्रतिस्थापित करेगा, वह हमारे प्रॉक्सीएसक्यूएल परिनियोजन के साथ ही रोलिंग अपडेट फैशन का उपयोग कर रहा है।

अगला भाग "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

इस खंड में, हम Kubernetes को Apache वेब सर्वर का उपयोग करके Wordpress 4.9 को परिनियोजित करने के लिए कह रहे हैं और हमने कंटेनर को "वर्डप्रेस" नाम दिया है। कंटेनर के हर बार डाउन होने पर फिर से चालू किया जाएगा, चाहे स्थिति कुछ भी हो। हम यह भी चाहते हैं कि कुबेरनेट्स कई पर्यावरण चर पारित करें:

WORDPRESS_DB_HOST - MySQL डेटाबेस होस्ट। चूँकि हम ProxySQL को एक सेवा के रूप में उपयोग कर रहे हैं, सेवा का नाम metadata.name का मान होगा। जो "प्रॉक्सीस्क्ल" है। ProxySQL पोर्ट 6033 पर MySQL लोड संतुलित कनेक्शन के लिए सुनता है जबकि ProxySQL व्यवस्थापन कंसोल 6032 पर है।
WORDPRESS_DB_USER - "डेटाबेस तैयार करना" अनुभाग के तहत बनाए गए वर्डप्रेस डेटाबेस उपयोगकर्ता को निर्दिष्ट करें।
WORDPRESS_DB_PASSWORD - WORDPRESS_DB_USER . के लिए पासवर्ड . चूंकि हम इस फाइल में पासवर्ड को उजागर नहीं करना चाहते हैं, हम इसे कुबेरनेट्स सीक्रेट्स का उपयोग करके छिपा सकते हैं। यहां हम कुबेरनेट्स को इसके बजाय "mysql-pass" गुप्त संसाधन पढ़ने का निर्देश देते हैं। पॉड परिनियोजन से पहले उन्नत में रहस्य बनाना पड़ता है, जैसा कि आगे बताया गया है।

हम अंतिम उपयोगकर्ता के लिए पॉड के पोर्ट 80 को भी प्रकाशित करना चाहते हैं। कंटेनर में /var/www/html के अंदर संग्रहीत Wordpress सामग्री NFS पर चल रहे हमारे सतत भंडारण में आरोहित की जाएगी। हम इस उद्देश्य के लिए PersistentVolume और PersistentVolumeClaim संसाधनों का उपयोग करेंगे जैसा कि "Wordpress के लिए Persistent Storage की तैयारी" अनुभाग के तहत दिखाया गया है।

"---" ब्रेक लाइन के बाद, हम सेवा नामक एक अन्य संसाधन को परिभाषित करते हैं:

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: frontend

इस कॉन्फ़िगरेशन में, हम चाहते हैं कि कुबेरनेट्स "वर्डप्रेस" नामक एक सेवा बनाए, बाहरी नेटवर्क के सभी नोड्स (उर्फ नोडपोर्ट) पर पोर्ट 30088 पर सुनें और इसे "ऐप =वर्डप्रेस, टियर =" लेबल वाले सभी पॉड्स पर पोर्ट 80 पर अग्रेषित करें। फ्रंटएंड"।

इसलिए, उपरोक्त हमारी YAML परिभाषा के आधार पर, हमें "वर्डप्रेस" पॉड और सेवा को परिनियोजित करने से पहले कई कुबेरनेट संसाधन तैयार करने होंगे:

PersistentVolume और PersistentVolumeClaim - हमारे Wordpress एप्लिकेशन की वेब सामग्री को संग्रहीत करने के लिए, इसलिए जब पॉड को अन्य वर्कर नोड में पुनर्निर्धारित किया जा रहा है, तो हम अंतिम परिवर्तन नहीं खोएंगे।
रहस्य - YAML फ़ाइल के अंदर Wordpress डेटाबेस उपयोगकर्ता पासवर्ड को छिपाने के लिए।

वर्डप्रेस के लिए स्थायी संग्रहण तैयार करना

कुबेरनेट्स के लिए एक अच्छा स्थायी भंडारण क्लस्टर में सभी कुबेरनेट्स नोड्स द्वारा सुलभ होना चाहिए। इस ब्लॉग पोस्ट के लिए, हमने NFS को PersistentVolume (PV) प्रदाता के रूप में उपयोग किया क्योंकि यह आसान और समर्थित आउट-ऑफ-द-बॉक्स है। NFS सर्वर हमारे Kubernetes नेटवर्क के बाहर कहीं स्थित है (जैसा कि पहले आर्किटेक्चर आरेख में दिखाया गया है) और हमने इसे /etc/exports के अंदर निम्नलिखित पंक्ति के साथ सभी Kubernetes नोड्स को अनुमति देने के लिए कॉन्फ़िगर किया है:

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

ध्यान दें कि सभी कुबेरनेट्स नोड्स पर एनएफएस क्लाइंट पैकेज स्थापित होना चाहिए। अन्यथा, Kubernetes NFS को सही ढंग से माउंट करने में सक्षम नहीं होगा। सभी नोड्स पर:

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

साथ ही, सुनिश्चित करें कि NFS सर्वर पर लक्ष्य निर्देशिका मौजूद है:

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

फिर, वर्डप्रेस-pv-pvc.yml नाम की एक फाइल बनाएं और निम्नलिखित पंक्तियाँ जोड़ें:

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: frontend

उपरोक्त परिभाषा में, हम कुबेरनेट्स को हमारे Wordpress कंटेनर के लिए NFS सर्वर पर 3GB वॉल्यूम स्पेस आवंटित करने के लिए कह रहे हैं। उत्पादन के उपयोग के लिए ध्यान दें, NFS को स्वचालित प्रोविजनर और स्टोरेज क्लास के साथ कॉन्फ़िगर किया जाना चाहिए।

PV और PVC संसाधन बनाएँ:

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

सत्यापित करें कि क्या वे संसाधन बनाए गए हैं और स्थिति "बाध्य" होनी चाहिए:

$ 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

वर्डप्रेस के लिए रहस्य तैयार करना

WORDPRESS_DB_PASSWORD के लिए Wordpress कंटेनर द्वारा उपयोग किए जाने के लिए एक रहस्य बनाएं पर्यावरणपरिवर्ती तारक। इसका कारण यह है कि हम पासवर्ड को YAML फ़ाइल के अंदर स्पष्ट टेक्स्ट में नहीं दिखाना चाहते हैं।

mysql-pass नामक एक गुप्त संसाधन बनाएं और उसके अनुसार पासवर्ड पास करें:

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

सत्यापित करें कि हमारा रहस्य बनाया गया है:

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

ProxySQL और Wordpress परिनियोजित करना

अंत में, हम तैनाती शुरू कर सकते हैं। पहले ProxySQL परिनियोजित करें, उसके बाद Wordpress:

$ kubectl create -f proxysql-rs-svc.yml
$ kubectl create -f wordpress-rs-svc.yml

फिर हम उन सभी पॉड्स और सेवाओं को सूचीबद्ध कर सकते हैं जो "फ्रंटएंड" टियर के तहत बनाई गई हैं:

$ 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>

उपरोक्त आउटपुट हमारे परिनियोजन आर्किटेक्चर को सत्यापित करता है जहां वर्तमान में हमारे पास तीन Wordpress पॉड हैं, जो सार्वजनिक रूप से पोर्ट 30088 पर और साथ ही हमारे ProxySQL इंस्टेंस के साथ-साथ पोर्ट 30033 और 30032 पर बाहरी रूप से प्लस 6033 और 6032 आंतरिक रूप से उजागर हैं।

इस समय, हमारी वास्तुकला कुछ इस तरह दिख रही है:

Wordpress पॉड्स द्वारा प्रकाशित पोर्ट 80 को अब पोर्ट 30088 के माध्यम से बाहरी दुनिया में मैप किया गया है। हम http://{any_kubernetes_host}:30088/ पर अपने ब्लॉग पोस्ट तक पहुंच सकते हैं और इसे Wordpress इंस्टॉलेशन पेज पर रीडायरेक्ट किया जाना चाहिए। अगर हम इंस्टॉलेशन के साथ आगे बढ़ते हैं, तो यह डेटाबेस कनेक्शन वाले हिस्से को छोड़ देगा और सीधे इस पेज को दिखाएगा:

यह इंगित करता है कि हमारा MySQL और ProxySQL कॉन्फ़िगरेशन wp-config.php फ़ाइल के अंदर सही ढंग से कॉन्फ़िगर किया गया है। अन्यथा, आपको डेटाबेस कॉन्फ़िगरेशन पृष्ठ पर पुनः निर्देशित किया जाएगा।

हमारी तैनाती अब पूरी हो गई है।

ProxySQL पॉड्स और सर्विस मैनेजमेंट

कुबेरनेट्स द्वारा विफलता और पुनर्प्राप्ति को स्वचालित रूप से नियंत्रित किए जाने की उम्मीद है। उदाहरण के लिए, यदि कुबेरनेट्स कार्यकर्ता नीचे चला जाता है, तो पॉड को अगले उपलब्ध नोड में --पॉड-बेदखली-टाइमआउट (डिफ़ॉल्ट रूप से 5 मिनट) के बाद फिर से बनाया जाएगा। यदि कंटेनर दुर्घटनाग्रस्त हो जाता है या मर जाता है, तो कुबेरनेट्स इसे लगभग तुरंत बदल देगा।

कुबेरनेट्स के भीतर चलते समय कुछ सामान्य प्रबंधन कार्यों के भिन्न होने की उम्मीद है, जैसा कि अगले अनुभागों में दिखाया गया है।

ProxySQL से कनेक्ट हो रहा है

जबकि ProxySQL बाहरी रूप से पोर्ट 30033 (MySQL) और 30032 (व्यवस्थापक) पर उजागर होता है, यह क्रमशः प्रकाशित पोर्ट, 6033 और 6032 के माध्यम से आंतरिक रूप से भी पहुँचा जा सकता है। इस प्रकार, Kubernetes नेटवर्क के भीतर ProxySQL इंस्टेंस तक पहुँचने के लिए, CLUSTER-IP, या सेवा नाम "proxysql" को होस्ट मान के रूप में उपयोग करें। उदाहरण के लिए, Wordpress पॉड के भीतर, आप निम्न आदेश का उपयोग करके ProxySQL व्यवस्थापक कंसोल तक पहुँच सकते हैं:

$ mysql -uproxysql-admin -p -hproxysql -P6032

यदि आप बाहरी रूप से कनेक्ट करना चाहते हैं, तो नोडपोर्ट वैल्यू के तहत परिभाषित पोर्ट का उपयोग करें जो वह वाईएएमएल की सेवा करता है और किसी भी कुबेरनेट्स नोड को होस्ट वैल्यू के रूप में चुनें:

$ mysql -uproxysql-admin -p -hkube3.local -P30032

यही बात पोर्ट 30033 (बाहरी) और 6033 (आंतरिक) पर MySQL लोड-बैलेंस कनेक्शन पर भी लागू होती है।

ऊपर और नीचे स्केलिंग

Kubernetes के साथ स्केलिंग करना आसान है:

$ kubectl scale deployment proxysql --replicas=5
deployment.extensions/proxysql scaled

रोलआउट स्थिति सत्यापित करें:

$ kubectl rollout status deployment proxysql
deployment "proxysql" successfully rolled out

नीचे स्केलिंग भी समान है। यहां हम 5 से 2 प्रतिकृतियों से वापस लौटना चाहते हैं:

$ kubectl scale deployment proxysql --replicas=2
deployment.extensions/proxysql scaled

हम "वर्णन" विकल्प का उपयोग करके इस परिनियोजन के लिए क्या हुआ है, इसकी बेहतर तस्वीर प्राप्त करने के लिए हम ProxySQL के लिए परिनियोजन घटनाओं को भी देख सकते हैं:

$ 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 2

पॉड्स के कनेक्शन कुबेरनेट्स द्वारा स्वचालित रूप से संतुलित लोड किए जाएंगे।

कॉन्फ़िगरेशन परिवर्तन

हमारे ProxySQL पॉड्स पर कॉन्फ़िगरेशन परिवर्तन करने का एक तरीका हमारे कॉन्फ़िगरेशन को किसी अन्य ConfigMap नाम का उपयोग करके संस्करणित करना है। सबसे पहले, हमारे कॉन्फ़िगरेशन फ़ाइल को सीधे अपने पसंदीदा टेक्स्ट एडिटर के माध्यम से संशोधित करें:

$ vim /root/proxysql.cnf

फिर, इसे किसी भिन्न नाम से Kubernetes ConfigMap में लोड करें। इस उदाहरण में, हम संसाधन नाम में "-v2" जोड़ते हैं:

$ kubectl create configmap proxysql-configmap-v2 --from-file=proxysql.cnf

सत्यापित करें कि ConfigMap सही ढंग से लोड किया गया है:

$ kubectl get configmap
NAME                    DATA   AGE
proxysql-configmap      1      3d15h
proxysql-configmap-v2   1      19m

ProxySQL परिनियोजन फ़ाइल खोलें, proxysql-rs-svc.yml और configMap अनुभाग के अंतर्गत निम्न पंक्ति को नए संस्करण में बदलें:

      volumes:
      - name: proxysql-config
        configMap:
          name: proxysql-configmap-v2 #change this line

फिर, हमारे ProxySQL परिनियोजन में परिवर्तन लागू करें:

$ kubectl apply -f proxysql-rs-svc.yml
deployment.apps/proxysql configured
service/proxysql configured

"वर्णन" ध्वज का उपयोग करके रेप्लिकासेट ईवेंट को देखकर रोलआउट सत्यापित करें:

$ 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 0

नए ConfigMap नाम के साथ "वॉल्यूम" अनुभाग पर ध्यान दें। आप आउटपुट के निचले भाग में परिनियोजन ईवेंट भी देख सकते हैं। इस बिंदु पर, हमारे नए कॉन्फ़िगरेशन को सभी ProxySQL पॉड्स में लोड किया गया है, जहां Kubernetes ने ProxySQL रेप्लिकासेट को 0 (RollingUpdate रणनीति का पालन करते हुए) तक छोटा किया और उन्हें 2 रेप्लिका की वांछित स्थिति में वापस लाया।

अंतिम विचार

इस बिंदु तक, हमने Kubernetes में ProxySQL के लिए संभावित परिनियोजन दृष्टिकोण को कवर किया है। Kubernetes ConfigMap की मदद से ProxySQL चलाने से ProxySQL क्लस्टरिंग की एक नई संभावना खुलती है, जहां यह ProxySQL के अंदर अंतर्निहित मूल क्लस्टरिंग समर्थन की तुलना में कुछ अलग है।

आगामी ब्लॉग पोस्ट में, हम Kubernetes ConfigMap का उपयोग करके ProxySQL क्लस्टरिंग का पता लगाएंगे और इसे सही तरीके से कैसे करें। बने रहें!