ProxySQLをKubernetesサービスとして実行する

分散データベースクラスターを実行する場合、ロードバランサーを前面に配置するのが一般的です。利点は明らかです。負荷分散、接続フェイルオーバー、および基盤となるデータベーストポロジからのアプリケーション層の分離です。よりインテリジェントな負荷分散には、ProxySQLやMaxScaleなどのデータベース対応プロキシが最適です。以前のブログでは、KubernetesでProxySQLをヘルパーコンテナとして実行する方法を紹介しました。このブログ投稿では、ProxySQLをKubernetesサービスとしてデプロイする方法を紹介します。サンプルアプリケーションとしてWordpressを使用し、データベースバックエンドはClusterControlを使用してデプロイされた2ノードのMySQLレプリケーションで実行されます。次の図は、インフラストラクチャを示しています。

この前のブログ投稿と同様の設定を展開するので、投稿を読みやすくするために、ブログ投稿の一部で重複することを期待してください。

Kubernetes上のProxySQL

少し要約することから始めましょう。 ProxySQLアーキテクチャの設計は主観的なトピックであり、アプリケーションの配置、データベースコンテナ、およびProxySQL自体の役割に大きく依存します。理想的には、次の2つの構成でKubernetesによって管理されるようにProxySQLを構成できます。

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

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

このブログ投稿では、最初の構成、つまりProxySQLをKubernetesサービスとして実行する方法について説明します。 2番目の構成についてはすでにここで説明しています。ヘルパーコンテナアプローチとは対照的に、サービスとして実行すると、ProxySQLポッドがアプリケーションから独立して動作し、KubernetesConfigMapを使用して簡単にスケーリングおよびクラスター化できます。これは、ProxySQLインスタンス（別名proxysql_servers）全体の構成チェックサムに依存するProxySQLネイティブクラスタリングサポートとは明らかに異なるクラスタリングアプローチです。 ClusterControlで簡単に作成されたProxySQLクラスタリングについて知りたい場合は、このブログ投稿を確認してください。

Kubernetesでは、ProxySQLのマルチレイヤー構成システムにより、ConfigMapを使用したポッドクラスタリングが可能になります。ただし、ProxySQLのネイティブクラスタリング機能と同じようにスムーズに機能させるには、いくつかの欠点と回避策があります。現時点では、ConfigMapの更新時にポッドに信号を送ることが作業中の機能です。このトピックについては、今後のブログ投稿でさらに詳しく説明します。

基本的に、ProxySQLポッドを作成し、Kubernetesネットワーク内または外部の他のポッドからアクセスできるようにKubernetesサービスをアタッチする必要があります。その後、アプリケーションは、構成されたポートでTCP/IPネットワークを介してProxySQLサービスに接続します。デフォルトは、MySQL負荷分散接続の場合は6033、ProxySQL管理コンソールの場合は6032です。複数のレプリカがある場合、ポッドへの接続は、すべてのKubernetesノードで実行されているKuberneteskube-proxyコンポーネントによって自動的に負荷分散されます。

KubernetesサービスとしてのProxySQL

このセットアップでは、ProxySQLとWordpressの両方をポッドとサービスとして実行します。次の図は、高レベルのアーキテクチャを示しています。

このセットアップでは、「wordpress」と「proxysql」の2つのポッドとサービスをデプロイします。デプロイメントとサービスの宣言をアプリケーションごとに1つのYAMLファイルにマージし、それらを1つのユニットとして管理します。アプリケーションコンテナのコンテンツを複数のノード間で永続的に保つには、クラスター化されたファイルシステムまたはリモートファイルシステム（この場合はNFS）を使用する必要があります。

ProxySQLをサービスとしてデプロイすると、ヘルパーコンテナアプローチにいくつかの優れた点がもたらされます。

Kubernetes ConfigMapアプローチを使用すると、ProxySQLを不変の構成でクラスター化できます。
KubernetesはProxySQLリカバリを処理し、インスタンスへの接続のバランスを自動的に調整します。
ClusterIPと呼ばれるKubernetes仮想IPアドレスを実装した単一のエンドポイント。
シェアードナッシングアーキテクチャを備えた一元化されたリバースプロキシ層。
Kubernetes以外の外部アプリケーションで使用できます。

ProxySQL用に2つのレプリカ、Wordpress用に3つのレプリカとしてデプロイを開始し、Kubernetesが提供する大規模な実行と負荷分散機能を示します。

データベースの準備

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

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というファイルを作成します次の行を追加します：

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は、「---」区切り文字で区切られた、ファイルに結合された2つのリソースで構成されます。最初のリソースはDeploymentであり、次の仕様を定義します。

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

上記は、2つのProxySQLポッドを「app =proxysql、tier=frontend」というラベルの付いたコンテナーに一致するReplicaSetとしてデプロイすることを意味します。展開戦略は、古いポッドを新しいポッドに置き換えるために使用される戦略を指定します。この展開では、RollingUpdateを選択しました。これは、ポッドがローリング更新方式で、一度に1つのポッドで更新されることを意味します。

次の部分はコンテナのテンプレートです：

      - 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。*内セクションでは、 somealnines / proxysqlを使用してProxySQLをデプロイするようにKubernetesに指示しています。イメージバージョン1.4.12。また、Kubernetesで事前構成されたカスタム構成ファイルをマウントし、コンテナー内の/etc/proxysql.cnfにマップする必要があります。実行中のポッドは、6033と6032の2つのポートを公開します。「ボリューム」セクションも定義します。このセクションでは、ボリュームマウントによってマウントされるProxySQLポッド内のボリュームとしてConfigMapをマウントするようにKubernetesに指示します。

2番目のリソースはサービスです。 Kubernetesサービスは、ポッドの論理セットとそれらにアクセスするためのポリシーを定義する抽象化レイヤーです。このセクションでは、以下を定義します。

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

この場合、ProxySQLに外部ネットワークからアクセスする必要があるため、NodePortタイプが選択されたタイプです。これにより、クラスター内のすべてのKubernetesノードでnodePortが公開されます。 NodePortリソースの有効なポートの範囲は30000〜32767です。 ProxySQLポッドのポート6033にマップされるMySQL負荷分散接続にはポート30033を選択し、6032にマップされるProxySQL管理ポートにはポート30032を選択しました。

したがって、上記の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は、ローカルホストのみを介したローカル接続用にデフォルトの「admin」ユーザーを予約します。したがって、ProxySQLインスタンスにリモートでアクセスするには、他のユーザーを使用する必要があります。そうしないと、次のエラーが発生します：

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

ProxySQL構成は、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

Wordpressポッドとサービスの定義

次に、次の行を wordpress-rs-svc.ymlというファイルに貼り付けます。 kubectlが構成されているホスト：

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は2つのリソースで構成され、ファイル内で結合された「---」区切り文字で区切られます。 1つ目は、「spec。*」セクションに示されているように、ReplicaSetとしてデプロイされるDeploymentリソースです。

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

このセクションでは、デプロイメントの仕様を示します。ラベル「app =wordpress、tier=backend」に一致する3つのポッドを開始します。デプロイ戦略はRollingUpdateです。つまり、Kubernetesがポッドを置き換える方法は、ProxySQLデプロイメントと同じローリングアップデート方式を使用することです。

次の部分は「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

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

WORDPRESS_DB_HOST -MySQLデータベースホスト。 ProxySQLをサービスとして使用しているため、サービス名は metadata.nameの値になります。これは「proxysql」です。 ProxySQL管理コンソールが6032にある間、ProxySQLはポート6033でMySQL負荷分散接続をリッスンします。
WORDPRESS_DB_USER -「データベースの準備」セクションで作成されたWordPressデータベースユーザーを指定します。
WORDPRESS_DB_PASSWORD - WORDPRESS_DB_USERのパスワード。このファイルでパスワードを公開したくないので、Kubernetesシークレットを使用してパスワードを非表示にすることができます。ここでは、代わりに「mysql-pass」シークレットリソースを読み取るようにKubernetesに指示します。さらに下で説明するように、ポッドを展開する前に、シークレットを事前に作成する必要があります。

また、エンドユーザー向けにポッドのポート80を公開したいと思います。コンテナの/var/ www / html内に保存されているWordpressコンテンツは、NFSで実行されている永続ストレージにマウントされます。「Wordpress用の永続ストレージの準備」セクションに示すように、この目的のためにPersistentVolumeおよびPersistentVolumeClaimリソースを使用します。

「---」ブレークラインの後に、サービスと呼ばれる別のリソースを定義します：

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

この構成では、Kubernetesで「wordpress」というサービスを作成し、すべてのノード（別名NodePort）のポート30088で外部ネットワークをリッスンし、「app =wordpress、tier=」というラベルの付いたすべてのポッドのポート80に転送します。フロントエンド」。

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

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

Wordpress用の永続ストレージの準備

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: 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のボリュームスペースを割り当てるようにKubernetesに指示しています。本番環境での使用に注意してください。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の秘密を準備する

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>

上記の出力は、現在ポート30088で公開されている3つのWordpressポッドと、外部でポート30033と30032、さらに内部で6033と6032で公開されているProxySQLインスタンスを使用しているデプロイメントアーキテクチャを確認します。

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

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

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

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

ProxySQLポッドとサービス管理

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

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

ProxySQLへの接続

ProxySQLはポート30033（MySQL）および30032（Admin）で外部に公開されていますが、公開されているポート6033および6032を介して内部的にもアクセスできます。したがって、Kubernetesネットワーク内のProxySQLインスタンスにアクセスするには、CLUSTER-IPまたはサービス名「proxysql」をホスト値として使用します。たとえば、Wordpressポッド内で、次のコマンドを使用してProxySQL管理コンソールにアクセスできます。

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

外部に接続する場合は、YAMLにサービスを提供するnodePort値で定義されたポートを使用し、ホスト値としてKubernetesノードのいずれかを選択します。

$ 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

ポッドへの接続は、Kubernetesによって自動的に負荷分散されます。

構成の変更

ProxySQLポッドの構成を変更する1つの方法は、別のConfigMap名を使用して構成をバージョン管理することです。まず、お気に入りのテキストエディタを使用して構成ファイルを直接変更します：

$ vim /root/proxysql.cnf

次に、それを別の名前でKubernetesConfigMapにロードします。この例では、リソース名に「-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

「describe」フラグを使用してReplicaSetイベントを確認し、ロールアウトを確認します。

$ 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 ReplicaSetを0にスケールダウンし（RollingUpdate戦略に従って）、2つのレプリカの目的の状態に戻します。

最終的な考え

これまで、KubernetesでのProxySQLの可能なデプロイアプローチについて説明してきました。 Kubernetes ConfigMapを使用してProxySQLを実行すると、ProxySQLクラスタリングの新しい可能性が開かれます。この可能性は、ProxySQLに組み込まれているネイティブクラスタリングサポートとは多少異なります。

今後のブログ投稿では、KubernetesConfigMapを使用したProxySQLクラスタリングとその正しい方法について説明します。しばらくお待ちください！