KubernetesでのヘルパーコンテナとしてのProxySQLの実行

ProxySQLは通常、アプリケーション層とデータベース層の間にあり、いわゆるリバースプロキシ層です。アプリケーションコンテナがKubernetesによって調整および管理されている場合は、データベースサーバーの前でProxySQLを使用することをお勧めします。

この投稿では、ポッド内のヘルパーコンテナとしてKubernetesでProxySQLを実行する方法を紹介します。サンプルアプリケーションとしてWordpressを使用します。データサービスは、次の図に示すように、ClusterControlを使用してデプロイされ、ベアメタルインフラストラクチャ上のKubernetesネットワークの外部に配置された2ノードのMySQLレプリケーションによって提供されます。

ProxySQLDockerイメージ

この例では、多目的に使用するために構築された一般的なパブリックイメージであるSevereninesによって維持されているProxySQLDockerイメージを使用します。イメージにはエントリポイントスクリプトが付属しておらず、Galera Clusterをサポートしています（MySQLレプリケーションの組み込みサポートに加えて）。ヘルスチェックの目的で追加のスクリプトが必要です。

基本的に、ProxySQLコンテナを実行するには、次のコマンドを実行するだけです。

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

このイメージでは、ProxySQL構成ファイルをマウントポイント/etc/proxysql.cnfにバインドすることをお勧めしますが、これをスキップして、後でProxySQL管理コンソールを使用して構成することもできます。構成例は、DockerHubページまたはGithubページに記載されています。

Kubernetes上のProxySQL

ProxySQLアーキテクチャの設計は主観的なトピックであり、アプリケーションとデータベースコンテナの配置、およびProxySQL自体の役割に大きく依存します。 ProxySQLはクエリをルーティングするだけでなく、クエリの書き換えやキャッシュにも使用できます。効率的なキャッシュヒットには、アプリケーションデータベースのワークロード用に特別に調整されたカスタム構成が必要になる場合があります。

理想的には、次の2つの構成でKubernetesによって管理されるようにProxySQLを構成できます。

KubernetesサービスとしてのProxySQL（集中型デプロイ）。
ポッド内のヘルパーコンテナとしてのProxySQL（分散展開）。

最初のオプションは非常に簡単で、ProxySQLポッドを作成し、それにKubernetesサービスをアタッチします。その後、アプリケーションは、構成されたポートのネットワークを介してProxySQLサービスに接続します。デフォルトは、MySQL負荷分散ポートの場合は6033、ProxySQL管理ポートの場合は6032です。この展開については、今後のブログ投稿で取り上げます。

2番目のオプションは少し異なります。 Kubernetesには「ポッド」と呼ばれる概念があります。ポッドごとに1つ以上のコンテナを作成できます。これらは、比較的緊密に結合されています。ポッドのコンテンツは常に同じ場所に配置され、同じスケジュールで実行され、共有コンテキストで実行されます。ポッドは、Kubernetesで管理可能な最小のコンテナユニットです。

次の図を見ると、両方の展開を簡単に区別できます。

ポッドに複数のコンテナーを含めることができる主な理由は、プライマリアプリケーションを支援するヘルパーアプリケーションをサポートするためです。ヘルパーアプリケーションの典型的な例は、データプラー、データプッシャー、およびプロキシです。多くの場合、ヘルパーアプリケーションとプライマリアプリケーションは相互に通信する必要があります。通常、これは、この演習で示すように、共有ファイルシステムを介して、またはループバックネットワークインターフェイスであるlocalhostを介して行われます。このパターンの例は、新しい更新についてGitリポジトリをポーリングするヘルパープログラムを備えたWebサーバーです。

このブログ投稿では、2番目の構成（ポッド内のヘルパーコンテナーとしてProxySQLを実行する）について説明します。

ポッドのヘルパーとしてのProxySQL

このセットアップでは、WordpressコンテナーのヘルパーコンテナーとしてProxySQLを実行します。次の図は、高レベルのアーキテクチャを示しています。

この設定では、ProxySQLコンテナはWordpressコンテナと緊密に結合されており、「ブログ」ポッドと名付けました。 Kubernetesワーカーノードがダウンした場合など、再スケジュールが発生した場合、これら2つのコンテナーは、次に使用可能なホスト上で1つの論理ユニットとして常に一緒に再スケジュールされます。アプリケーションコンテナのコンテンツを複数のノード間で永続的に保つには、クラスター化されたファイルシステムまたはリモートファイルシステム（この場合はNFS）を使用する必要があります。

ProxySQLの役割は、データベース抽象化レイヤーをアプリケーションコンテナーに提供することです。バックエンドデータベースサービスとして2ノードのMySQLレプリケーションを実行しているため、両方のMySQLサーバーでリソース消費を最大化するには、読み取りと書き込みの分割が不可欠です。 ProxySQLはこれに優れており、アプリケーションへの変更は最小限またはまったく必要ありません。

この設定でProxySQLを実行すると、他にも多くの利点があります。

Kubernetesで実行されているアプリケーション層に最も近いクエリキャッシュ機能を提供します。
ProxySQLUNIXソケットファイルを介して接続することによる安全な実装。これは、サーバーとクライアントが接続してリクエストとデータを交換するために使用できるパイプのようなものです。
シェアードナッシングアーキテクチャを備えた分散型リバースプロキシ層。
「スキップネットワーク」の実装により、ネットワークのオーバーヘッドが減少します。
KubernetesConfigMapsを利用したステートレスデプロイアプローチ。

データベースの準備

マスター上にワードプレスデータベースとユーザーを作成し、正しい権限で割り当てます：

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;

ポッドの準備

次に、次の行をコピーして blog-deployment.ymlというファイルに貼り付けます。 kubectlが構成されているホスト：

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: {}

YAMLファイルには多くの行があり、興味深い部分だけを見てみましょう。最初のセクション：

apiVersion: apps/v1
kind: Deployment

最初の行はapiVersionです。 Kubernetesクラスターはv1.12で実行されているため、Kubernetes v1.12 APIのドキュメントを参照し、このAPIに従ったリソース宣言に従う必要があります。次は種類です。これは、デプロイするリソースの種類を示します。 Deployment、Service、ReplicaSet、DaemonSet、PersistentVolumeなどがその例です。

次の重要なセクションは「コンテナ」セクションです。ここでは、このポッドで一緒に実行するすべてのコンテナを定義します。最初の部分は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

このセクションでは、ApacheWebサーバーを使用してWordpress4.9をデプロイするようにKubernetesに指示し、コンテナーに「wordpress」という名前を付けました。また、Kubernetesにいくつかの環境変数を渡してもらいたい：

WORDPRESS_DB_HOST -データベースホスト。 ProxySQLコンテナはWordpressコンテナと同じポッドにあるため、代わりにProxySQLソケットファイルを使用する方が安全です。 Wordpressでソケットファイルを使用する形式は「localhost：{ソケットファイルへのパス}」です。デフォルトでは、ProxySQLコンテナの/tmpディレクトリの下にあります。この/tmpパスは、さらに下に示すように、「shared-data」volumeMountsを使用してWordpressとProxySQLコンテナー間で共有されます。 / tmpディレクトリの下で同じコンテンツを共有するには、両方のコンテナがこのボリュームをマウントする必要があります。
WORDPRESS_DB_USER -WordPressデータベースのユーザーを指定します。
WORDPRESS_DB_PASSWORD - WORDPRESS_DB_USERのパスワード。このファイルでパスワードを公開したくないので、Kubernetesシークレットを使用してパスワードを非表示にすることができます。ここでは、代わりに「mysql-pass」シークレットリソースを読み取るようにKubernetesに指示します。さらに下で説明するように、ポッドを展開する前に、シークレットを事前に作成する必要があります。

また、エンドユーザー向けにコンテナのポート80を公開したいと思います。コンテナの/var/ www / html内に保存されているWordpressコンテンツは、NFSで実行されている永続ストレージにマウントされます。

次に、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

上記のセクションでは、 somealnines / proxysqlを使用してProxySQLをデプロイするようにKubernetesに指示しています。イメージバージョン1.4.12。また、Kubernetesで事前構成されたカスタム構成ファイルをマウントし、コンテナー内の/etc/proxysql.cnfにマップする必要があります。「shared-data」と呼ばれるボリュームがあり、Wordpressイメージと共有するために/ tmpディレクトリにマップされます。これは、ポッドの存続期間を共有する一時ディレクトリです。これにより、データベースに接続するときに、TCP / IPネットワーキングをバイパスして、ProxySQLソケットファイル（/tmp/proxysql.sock）をWordpressコンテナで使用できるようになります。

最後の部分は「ボリューム」セクションです：

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

Kubernetesは、このポッド用に3つのボリュームを作成する必要があります：

wordpress-persistent-storage- PersistentVolumeClaimを使用します Wordpressコンテンツの永続的なデータストレージ用のコンテナにNFSエクスポートをマッピングするためのリソース。
proxysql-config- ConfigMapを使用します ProxySQL構成ファイルをマップするためのリソース。
shared-data- emptyDirを使用しますポッド内のコンテナの共有ディレクトリをマウントするためのリソース。 emptyDir リソースは、ポッドの存続期間を共有する一時的なディレクトリです。

したがって、上記のYAML定義に基づいて、「ブログ」ポッドのデプロイを開始する前に、いくつかのKubernetesリソースを準備する必要があります。

PersistentVolume およびPersistentVolumeClaim -WordpressアプリケーションのWebコンテンツを保存し、ポッドが他のワーカーノードに再スケジュールされているときに、最後の変更が失われることはありません。
秘密 -WordpressデータベースのユーザーパスワードをYAMLファイル内に非表示にします。
ConfigMap -構成ファイルをProxySQLコンテナーにマップし、他のノードに再スケジュールされるときに、Kubernetesが自動的に再マウントできるようにします。

Docker上のSevereninesMySQL：データベースをコンテナ化する方法Dockerコンテナ仮想化の上でMySQLサービスを実行することを検討する際に理解する必要があるすべてを発見するホワイトペーパーをダウンロードする

PersistentVolumeおよびPersistentVolumeClaim

Kubernetesの適切な永続ストレージには、クラスター内のすべてのKubernetesノードからアクセスできる必要があります。このブログ投稿のために、NFSをPersistentVolume（PV）プロバイダーとして使用しました。これは、NFSが簡単で、すぐにサポートされるためです。 NFSサーバーはKubernetesネットワークの外部にあり、/ etc/exports内に次の行を持つすべてのKubernetesノードを許可するように構成されています。

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

NFSクライアントパッケージはすべてのKubernetesノードにインストールする必要があることに注意してください。そうしないと、KubernetesはNFSを正しくマウントできません。すべてのノード：

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

また、NFSサーバーにターゲットディレクトリが存在することを確認してください：

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

次に、 wordpress-pv-pvc.ymlというファイルを作成します次の行を追加します：

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

上記の定義では、Kubernetesが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

秘密

1つ目は、Wordpressコンテナが WORDPRESS_DB_PASSWORDに使用するシークレットを作成することです。環境変数。その理由は、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

ConfigMap

また、ProxySQLコンテナのConfigMapリソースを作成する必要があります。 Kubernetes ConfigMapファイルは、ポッドで使用したり、構成データの保存に使用したりできる構成データのキーと値のペアを保持します。 ConfigMapsを使用すると、構成アーティファクトを画像コンテンツから切り離して、コンテナー化されたアプリケーションの移植性を維持できます。

データベースサーバーは、静的なホスト名とIPアドレスに加えて、静的な監視ユーザー名とパスワードを使用してベアメタルサーバーで既に実行されているため、このユースケースでは、ConfigMapファイルに使用するProxySQLサービスに関する事前構成済みの構成情報が格納されます。

まず、proxysql.cnfというテキストファイルを作成し、次の行を追加します。

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

「mysql_servers」セクションと「mysql_users」セクションに特に注意してください。データベースクラスターの設定に合わせて値を変更する必要がある場合があります。この場合、ClusterControlから取得した次のトポロジのスクリーンショットに要約されているように、MySQLレプリケーションで実行されている2つのデータベースサーバーがあります。

「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

ポッドの展開

これで、ブログポッドを展開できます。デプロイジョブをKubernetesに送信します：

$ kubectl create -f blog-deployment.yml

ポッドのステータスを確認します：

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

READY列の下に2/2が表示されている必要があります。これは、ポッド内で2つのコンテナーが実行されていることを示します。 -cオプションフラグを使用して、ブログポッド内のWordpressおよびProxySQLコンテナーを確認します。

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

ProxySQLコンテナログから、次の行が表示されます。

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（ライターホストグループ）には1つのONLINEノード（単一のマスターを示す）のみが必要であり、もう1つのホストは少なくともOFFLINE_HARDステータスである必要があります。 HID 20の場合、すべてのノードでオンラインであることが期待されます（複数のリードレプリカを示します）。

デプロイメントの要約を取得するには、describeフラグを使用します：

$ kubectl describe deployments blog

ブログは現在実行中ですが、次のセクションで説明するように、サービスを構成せずにKubernetesネットワークの外部からブログにアクセスすることはできません。

ブログサービスの作成

最後のステップは、ポッドへのサービスのアタッチを作成することです。これは、Wordpressブログポッドに外部からアクセスできるようにするためです。 blog-svc.ymlというファイルを作成します次の行を貼り付けます：

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

サービスを作成します：

$ kubectl create -f blog-svc.yml

サービスが正しく作成されているかどうかを確認します：

[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

ブログポッドによって公開されたポート80は、ポート30080を介して外部にマッピングされます。http：// {any_kubernetes_host}：30080 /でブログ投稿にアクセスでき、Wordpressのインストールページにリダイレクトする必要があります。インストールを続行すると、データベース接続部分がスキップされ、次のページが直接表示されます：

これは、MySQLとProxySQLの構成がwp-config.phpファイル内で正しく構成されていることを示しています。そうしないと、データベース構成ページにリダイレクトされます。

これで展開が完了しました。

ポッド内のProxySQLコンテナの管理

フェイルオーバーとリカバリは、Kubernetesによって自動的に処理されることが期待されています。たとえば、Kubernetesワーカーがダウンした場合、ポッドは--pod-eviction-timeout（デフォルトは5分）の後に次に使用可能なノードに再作成されます。コンテナがクラッシュまたは強制終了された場合、Kubernetesはほぼ瞬時にコンテナを置き換えます。

次のセクションで示すように、Kubernetes内で実行すると、いくつかの一般的な管理タスクが異なることが予想されます。

スケールアップとスケールダウン

上記の構成では、デプロイメントに1つのレプリカをデプロイしていました。スケールアップするには、 spec.replicasを変更するだけです。 kubectl editコマンドを使用してそれに応じて値を設定します：

$ kubectl edit deployment blog

デフォルトのテキストファイルでデプロイメント定義を開き、 spec.replicasを変更するだけです。たとえば、「replicas：3」など、より高い値に値を付けます。次に、ファイルを保存し、次のコマンドを使用してロールアウトステータスをすぐに確認します。

$ 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

この時点で、Kubernetesで3つのブログポッド（Wordpress + ProxySQL）が同時に実行されています：

$ 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

この時点で、私たちのアーキテクチャは次のようになっています。

水平スケールの本番環境でWordpressをスムーズに実行するには、現在の構成よりも多くのカスタマイズが必要になる場合があることに注意してください（静的コンテンツ、セッション管理などについて考えてください）。これらは実際にはこのブログ投稿の範囲を超えています。

スケールダウン手順も同様です。

構成管理

ProxySQLでは構成管理が重要です。ここで魔法が起こり、クエリのキャッシュ、ファイアウォール、書き換えを行うための独自のクエリルールのセットを定義できます。 ProxySQLが管理コンソールを介して構成され、「SAVE .. TO DISK」を使用して永続性にプッシュする一般的な方法とは異なり、Kubernetesでの移植性を高めるためにのみ構成ファイルを使用します。これが、ConfigMapsを使用している理由です。

Kubernetes ConfigMapsによって保存された一元化された構成に依存しているため、構成の変更を実行する方法はいくつかあります。まず、kubectl editコマンドを使用して：

$ kubectl edit configmap proxysql-configmap

デフォルトのテキストエディタで設定が開き、直接変更を加えて、完了したらテキストファイルを保存できます。それ以外の場合は、構成マップを再作成して、次のことも行う必要があります。

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

構成がConfigMapにプッシュされたら、「サービス制御」セクションに示されているようにポッドまたはコンテナーを再起動します。 ProxySQL管理インターフェース（ポート6032）を介してコンテナーを構成しても、Kubernetesによるポッドの再スケジュール後にコンテナーが永続化されることはありません。

サービス制御

ポッド内の2つのコンテナは緊密に結合されているため、ProxySQL構成の変更を適用する最善の方法は、Kubernetesにポッドの置き換えを強制することです。スケールアップした後、現在3つのブログポッドがあるとします。

$ 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

次のコマンドを使用して、一度に1つのポッドを交換します。

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

次に、次のことを確認します。

$ 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

AGE列とRESTART列を見ると、最新のポッドが再起動されていることがわかります。別のポッド名が表示されています。残りのポッドについても同じ手順を繰り返します。それ以外の場合は、「docker kill」コマンドを使用して、Kubernetesワーカーノード内でProxySQLコンテナーを手動で強制終了することもできます。例：

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

その後、Kubernetesは強制終了されたProxySQLコンテナを新しいコンテナに置き換えます。

監視

kubectl execコマンドを使用して、mysqlクライアントを介してSQLステートメントを実行します。たとえば、クエリの消化を監視するには：

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

またはワンライナー付き：

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

SQLステートメントを変更することにより、この管理コンソールを介して他のProxySQLコンポーネントを監視したり、管理タスクを実行したりできます。繰り返しになりますが、ProxySQLコンテナの存続期間中のみ持続し、ポッドが再スケジュールされた場合は持続しません。

最終的な考え

ProxySQLは、アプリケーションコンテナを拡張し、分散データベースバックエンドにアクセスするインテリジェントな方法を使用する場合に重要な役割を果たします。大規模な実行時にアプリケーションの成長をサポートするために、ProxySQLをKubernetesにデプロイする方法はいくつかあります。このブログ投稿はそのうちの1つだけをカバーしています。

今後のブログ投稿では、ProxySQLをKubernetesサービスとして使用して一元化されたアプローチで実行する方法について説明します。