Skip to content
logo
Percona Operator for MySQL
How to install Percona XtraDB Cluster in multi-namespace (cluster-wide) mode
Initializing search
    percona/k8spxc-docs
    percona/k8spxc-docs
    • Welcome
      • System Requirements
      • Design and architecture
      • Comparison with other solutions
      • Install with Helm
      • Install with kubectl
      • Install on Minikube
      • Install on Google Kubernetes Engine (GKE)
      • Install on Amazon Elastic Kubernetes Service (AWS EKS)
      • Install on Microsoft Azure Kubernetes Service (AKS)
      • Install on OpenShift
      • Generic Kubernetes installation
      • Multi-cluster and multi-region deployment
      • Application and system users
      • Changing MySQL Options
      • Anti-affinity and tolerations
      • Labels and annotations
      • Local Storage support
      • Defining environment variables
      • Load Balancing with HAProxy
      • Load Balancing with ProxySQL
      • Transport Encryption (TLS/SSL)
      • Data at rest encryption
      • Telemetry
      • Backup and restore
      • Upgrade Database and Operator
      • Horizontal and vertical scaling
      • Monitor with Percona Monitoring and Management (PMM)
      • Add sidecar containers
      • Restart or pause the cluster
      • Crash recovery
      • Debug and troubleshoot
      • How to install Percona XtraDB Cluster in multi-namespace (cluster-wide) mode
      • How to upgrade Percona XtraDB Cluster manually
      • How to use private registry
      • Custom Resource options
      • Percona certified images
      • Operator API
      • Frequently Asked Questions
      • Old releases (documentation archive)
      • Release notes index
      • Percona Operator for MySQL based on Percona XtraDB Cluster 1.12.0 (2022-12-07)
      • Percona Operator for MySQL based on Percona XtraDB Cluster 1.11.0 (2022-06-03)
      • Percona Distribution for MySQL Operator 1.10.0 (2021-11-24)
      • Percona Distribution for MySQL Operator 1.9.0 (2021-08-09)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.8.0 (2021-05-26)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.7.0 (2021-02-02)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.6.0 (2020-09-09)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.5.0 (2020-07-21)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.4.0 (2020-04-29)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.3.0 (2020-01-06)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.2.0 (2019-09-20)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.1.0 (2019-07-15)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.0.0 (2019-05-29)

    Install Percona XtraDB Cluster in multi-namespace (cluster-wide) mode¶

    By default, Percona Operator for MySQL based on Percona XtraDB Cluster functions in a specific Kubernetes namespace. You can create one during installation (like it is shown in the installation instructions) or just use the default namespace. This approach allows several Operators to co-exist in one Kubernetes-based environment, being separated in different namespaces:

    image

    Still, sometimes it is more convenient to have one Operator watching for Percona XtraDB Cluster custom resources in several namespaces.

    We recommend running Percona Operator for MySQL in a traditional way, limited to a specific namespace. But it is possible to run it in so-called cluster-wide mode, one Operator watching several namespaces, if needed:

    image

    Note

    Please take into account that if several Operators are configured to watch the same namespace, it is entirely unpredictable which one will get ownership of the Custom Resource in it, so this situation should be avoided.

    To use the Operator in such cluster-wide mode, you should install it with a different set of configuration YAML files, which are available in the deploy folder and have filenames with a special cw- prefix: e.g. deploy/cw-bundle.yaml.

    While using this cluster-wide versions of configuration files, you should set the following information there:

    • subjects.namespace option should contain the namespace which will host the Operator,

    • WATCH_NAMESPACE key-value pair in the env section should have value equal to a comma-separated list of the namespaces to be watched by the Operator (or just a blank string to make the Operator deal with all namespaces in a Kubernetes cluster).

      Note

      The list of namespaces to watch is fully supported by the Operator starting from the version 1.7 (in the version 1.6 you can only use cluster-wide mode with empty WATCH_NAMESPACE key to watch all namespaces). Also, prior to the version 1.12.0 it was necessary to mention the Operator’s own namespace in the list of watched namespaces.

      The following simple example shows how to install Operator cluster-wide on Kubernetes.

    • First of all, clone the percona-xtradb-cluster-operator repository:

      $ git clone -b v1.12.0 https://github.com/percona/percona-xtradb-cluster-operator
      $ cd percona-xtradb-cluster-operator
      
    • Let’s suppose that Operator’s namespace should be the pxc-operator one. Create it as follows:

      $ kubectl create namespace pxc-operator
      

      Namespaces to be watched by the Operator should be created in the same way if not exist. Let’s say the Operator should watch the pxc namespace:

      $ kubectl create namespace pxc
      
    • Apply the deploy/cw-bundle.yaml file with the following command:

      $ kubectl apply -f deploy/cw-bundle.yaml -n pxc-operator
      
    • After the Operator is started, Percona XtraDB Cluster can be created at any time by applying the deploy/cr.yaml configuration file, like in the case of normal installation:

      $ kubectl apply -f deploy/cr.yaml -n pxc
      

      The creation process will take some time. The process is over when both operator and replica set Pods have reached their Running status:

      NAME                                               READY   STATUS    RESTARTS   AGE
      cluster1-haproxy-0                                 2/2     Running   0          6m17s
      cluster1-haproxy-1                                 2/2     Running   0          4m59s
      cluster1-haproxy-2                                 2/2     Running   0          4m36s
      cluster1-pxc-0                                     3/3     Running   0          6m17s
      cluster1-pxc-1                                     3/3     Running   0          5m3s
      cluster1-pxc-2                                     3/3     Running   0          3m56s
      percona-xtradb-cluster-operator-79966668bd-rswbk   1/1     Running   0          9m54s
      
    • Check the connectivity to the newly created cluster.

      First you will need the login and password for the admin user to access the cluster. Use kubectl get secrets command to see the list of Secrets objects (by default the Secrets object you are interested in has cluster1-secrets name). You can use the following command to get the password of the root user:

      $ kubectl get secrets --namespace=pxc cluster1-secrets -o yaml -o jsonpath='{.data.root}' | base64 --decode | tr '\n' ' ' && echo " "
      

      Now run a container with mysql tool and connect its console output to your terminal. The following command will do this, naming the new Pod percona-client:

      $ kubectl run -i --rm --tty percona-client --image=percona:5.7 --restart=Never --env="POD_NAMESPACE=pxc" -- bash -il
      

      Executing it may require some time to deploy the correspondent Pod.

      Now run mysql tool in the percona-client command shell using the password obtained from the secret. The command will look different depending on whether your cluster provides load balancing with HAProxy (the default choice) or ProxySQL:

      $ mysql -h cluster1-haproxy -uroot -p<root_password>
      
      $ mysql -h cluster1-proxysql -uroot -p<root_password>
      

    Note

    Some Kubernetes-based environments are specifically configured to have communication across Namespaces is not allowed by default network policies. In this case, you should specifically allow the Operator communication across the needed Namespaces. Following the above example, you would need to allow ingress traffic for the pxc-operator Namespace from the pxc Namespace, and also from the default Namespace. You can do it with the NetworkPolicy resource, specified in the YAML file as follows:

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: percona
      namespace: pxc-operator
    spec:
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: pxc
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: default
      podSelector: {}
      policyTypes:
      - Ingress
    

    Don’t forget to apply the resulting file with the usual kubectl apply command.

    You can find more details about Network Policies in the official Kubernetes documentation.

    Contact Us

    For free technical help, visit the Percona Community Forum.

    To report bugs or submit feature requests, open a JIRA ticket.

    For paid support and managed or consulting services , contact Percona Sales.


    Last update: 2023-02-09
    Back to top
    Percona LLC and/or its affiliates, © 2009 - 2022
    Made with Material for MkDocs

    Cookie consent

    We use cookies to recognize your repeated visits and preferences, as well as to measure the effectiveness of our documentation and whether users find what they're searching for. With your consent, you're helping us to make our documentation better.