Providing you have a license to use Tungsten Clustering, you will be able to deploy one or more Tungsten Connectors in your Kubernetes environment. The following sections walk you through the process of deployment.
The following prerequisites are required for enabling this deployment method:
A Kubernetes cluster running a minimum version of 1.19
The kubectl cli tool configured to access your cluster
The appropriate Tungsten Connector Docker images (See Section 7.12.2.3, “Downloading the images” for details).
Access to your Tungsten Cluster database nodes. In the examples that follow, we refer to these
as db1, db2 and
db3
A number of files are used as part of the configuration and deployment, the table below lists the files and their general purpose
The image is available as a gzipped tar ball, and should be downlaoded to your local host from the Continuent Download portal.
Download the correct file for your environment into a suitable directory, and then unpack the file, for example:
shell>cd /opt/continuent/software/shell>tar zxvf tungsten-connector-docker-${VERSION}-${ARCH}.tar.gz
where:
VERSION = Tungsten Connector version with build number like 8.0.3-38
ARCH = { amd64 | arm64 }
Now that the file is downloaded, we need to load it into your local Docker daemon and push to the registry.
The examples below use the Intel (amd64) architecture files and commands applicable to loading into an AWS ECR Docker registry. Syntax may differ for other environments and should be adjusted accordingly.
shell>export ARCH=amd64shell>export RELEASE=8.0.3-38shell>export REGION=us-east-1shell>export REGISTRY=111222333444.dkr.ecr.us-east-1.amazonaws.comshell>cd /opt/continuent/software/tungsten-connector-docker-${RELEASE}shell>docker load -i images/tungsten-connector-_${RELEASE}-${ARCH}.tar
Retrieve an authentication token and authenthicate the Docker client to the ECR registry:
shell> aws ecr get-login-password --region ${REGION} | docker login --username AWS --password-stdin ${REGISTRY}Tag the images:
shell> docker tag tungsten-connector:${RELEASE} ${REGISTRY}/tungsten-connector:${RELEASE}Finally, push the images to the Docker Registry:
shell> docker push ${REGISTRY}/tungsten-connector:${RELEASE}This step is only required if your database hostnames cannot be resolved via DNS in your Kubernetes cluster.
If your databases are accessible via DNS (e.g., db1.example.com), skip this step and ensure your cluster topology uses the correct FQDNs.
If DNS resolution is NOT available, uncomment and configure the hostAliases section in
deployment.yaml (lines 21-30), for example:
hostAliases: - ip: "10.0.1.10" # Replace with actual db1 IP hostnames: - "db1" - ip: "10.0.1.11" # Replace with actual db2 IP hostnames: - "db2" - ip: "10.0.1.12" # Replace with actual db3 IP hostnames: - "db3"
Edit the configmap-tungsten.yaml file (lines 34-37) to match your cluster
configuration. To ensure correct spelling etc, you can copy the relevant stanzas directly from
you Cluster /etc/tungsten/tungsten.ini file, for example:
[alpha] topology=clustered master=db1 members=db1,db2,db3
By default, the manifests shipped with the packages have security disabled, therefore adjust accordingly based on your options below
The manifests are pre-configured with security disabled. This is the quickest way to get started.
The security settings that are configured by default, are within the configmap-tungsten.yaml,
an example is shown below:
disable-security-controls=true connector-ssl-capable=false connector-driver-options=?useSSL=false
In the deployment.yaml file, the security volume mounts are commented out.
Initiate deployment without security
Apply all manifests (secret-security.yaml is optional without security)
using the kubectl command.
shell>kubectl apply -f namespace.yamlshell>kubectl apply -f configmap-tungsten.yamlshell>kubectl apply -f configmap-listeners.yamlshell>kubectl apply -f secret-credentials.yamlshell>kubectl apply -f deployment.yamlshell>kubectl apply -f service.yaml
Or, apply them all at once:
shell> kubectl apply -f .To test without SSL, get the LoadBalancer external IP:
shell> kubectl -n tungsten-connector get service tungsten-connector
Wait for the EXTERNAL-IP to be assigned, then connect,
replacing <EXTERNAL-IP> with the actual IP from the command above:
shell> mysql -h <EXTERNAL-IP> -u app_user -psecret -P 3306If you want to enable SSL/TLS security, follow these steps:
Enable Security in Configuration
Edit configmap-tungsten.yaml and change these three settings
Change from true to
false:
disable-security-controls=false
Change from fasle to
true:
connector-ssl-capable=true
Change from '?useSSL=false' to
'?useSSL=true'
connector-driver-options=?useSSL=true
Required SSL Certificate Files
You must obtain these files from an existing Tungsten Cluster node
(typically from /opt/continuent/share) where security is enabled:
passwords.store tungsten_keystore.jks tungsten_truststore.ts tungsten_connector_keystore.jks tungsten_connector_truststore.ts tungsten_tls_keystore.jks
Add SSL Certificates to Secret
Base64-encode each file:
shell>cat passwords.store | base64shell>cat tungsten_keystore.jks | base64shell>cat tungsten_truststore.ts | base64shell>cat tungsten_connector_keystore.jks | base64shell>cat tungsten_connector_truststore.ts | base64shell>cat tungsten_tls_keystore.jks | base64
Edit secret-security.yaml and uncomment the
data: section (around line 67),
then add the base64-encoded content:
data: passwords.store: >BASE64_ENCODED_CONTENT< tungsten_keystore.jks: >BASE64_ENCODED_CONTENT< tungsten_truststore.ts: >BASE64_ENCODED_CONTENT< tungsten_connector_keystore.jks: >BASE64_ENCODED_CONTENT< tungsten_connector_truststore.ts: >BASE64_ENCODED_CONTENT< tungsten_tls_keystore.jks: >BASE64_ENCODED_CONTENT<
Uncomment Security Volume Mounts
Edit deployment.yaml and uncomment the security sections:
Uncomment the lines for the Volume Mounts (around lines 111-120):
- name: tungsten-security mountPath: /opt/continuent/tungsten/cluster-home/conf/security.properties subPath: security.properties readOnly: true - name: ssl-certs mountPath: /opt/continuent/share readOnly: true
Uncomment the lines for the Volumes (around lines 138-163):
- name: tungsten-security
secret:
secretName: tungsten-security
items:
- key: security.properties
path: security.properties
- name: ssl-certs
secret:
secretName: tungsten-security
optional: true
items:
- key: passwords.store
path: passwords.store
- key: tungsten_keystore.jks
path: tungsten_keystore.jks
- key: tungsten_truststore.ts
path: tungsten_truststore.ts
- key: tungsten_connector_keystore.jks
path: tungsten_connector_keystore.jks
- key: tungsten_connector_truststore.ts
path: tungsten_connector_truststore.ts
- key: tungsten_tls_keystore.jks
path: tungsten_tls_keystore.jksDeploy with Security
Apply all manifests using the kubectl command:
shell>kubectl apply -f namespace.yamlshell>kubectl apply -f configmap-tungsten.yamlshell>kubectl apply -f configmap-listeners.yamlshell>kubectl apply -f secret-credentials.yamlshell>kubectl apply -f secret-security.yamlshell>kubectl apply -f deployment.yamlshell>kubectl apply -f service.yaml
Or apply all at once:
shell> kubectl apply -f .To test with SSL:
Get the LoadBalancer external IP:
shell> kubectl -n tungsten-connector get service tungsten-connectorWait for EXTERNAL-IP to be assigned, then connect with SSL replacing <EXTERNAL-IP> with the actual IP from the command above
shell> mysql -h <EXTERNAL-IP> -u app_user -psecret -P 3306 \
--ssl-ca=ca.pem \
--ssl-cert=client-cert.pem \
--ssl-key=client-key.pem \
--ssl-verify-server-cert=false
Edit configmap-tungsten.yaml, line 12:
application-password=secret
Then restart the deployment:
shell>kubectl apply -f configmap-tungsten.yamlshell>kubectl -n tungsten-connector rollout restart deployment/tungsten-connector
By default, the connector runs in Bridge Mode. Only follow these steps if you need Proxy Mode.
Edit configmap-tungsten.yaml, line 30:
Change from true to
false
connector-bridge-mode=false
Add users to the secret-credentials.yaml in the user.map section:
stringData:
user.map: |
# <user> <password> <service> [affinity]
user1 password1 alpha
user2 password2 alpha db1Apply the changes:
shell>kubectl apply -f configmap-tungsten.yamlshell>kubectl apply -f secret-credentials.yamlshell>kubectl -n tungsten-connector rollout restart deployment/tungsten-connector
Edit deployment.yaml, lines 50-55:
resources:
requests:
memory: "2560Mi"
cpu: "500m"
limits:
memory: "3072Mi"
cpu: "2000m"
Edit service.yaml, line 7 to change from LoadBalancer:
spec: type: ClusterIP # or NodePort, or LoadBalancer
View all resources:
shell> kubectl -n tungsten-connector get allCheck pod status
shell> kubectl -n tungsten-connector get podsView pod details
shell> kubectl -n tungsten-connector describe pod <pod-name>Follow logs
shell> kubectl -n tungsten-connector logs -f deployment/tungsten-connectorView recent logs
shell> kubectl -n tungsten-connector logs --tail=100 deployment/tungsten-connectorFirst, get the LoadBalancer external IP:
shell> kubectl -n tungsten-connector get service tungsten-connectorWait for EXTERNAL-IP to be assigned. Example output:
# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) # tungsten-connector LoadBalancer 10.96.123.45 203.0.113.10 3306:30001/TCP,3307:30002/TCP...
Once the EXTERNAL-IP is assigned, test connectivity to each port, replacing <EXTERNAL-IP> with the actual LoadBalancer IP
MySQL Read-Write Port (3306)
shell> mysql -h <EXTERNAL-IP> -u app_user -psecret -P 3306 -e "SELECT @@hostname"MySQL Read-Only Port (3307)
shell> mysql -h <EXTERNAL-IP> -u app_user -psecret -P 3307 -e "SELECT @@hostname"Prometheus Metrics (8093)
shell> curl http://<EXTERNAL-IP>:8093/metricsREST API (8096)
shell> curl -u app_user:secret http://<EXTERNAL-IP>:8096/api/infoIf the Pod is not starting, check events:
shell> kubectl -n tungsten-connector describe pod <pod-name>and check logs for further information on why the pod is failing:
shell> kubectl -n tungsten-connector logs <pod-name>Missing SSL Certificates
If security is enabled, ensure all certificate files are added to secret-security.yaml
Database Connection Failed
Verify database hostnames are resolvable via DNS
If using hostAliases, verify the IPs are correct and databases are reachable
Check network policies allow connectivity from the connector pod
Authentication Failed
Check application-password in configmap-tungsten.yaml matches database credentials
Liveness/Readiness Probe Failures
Connector may need more time to start. Check logs for errors