Skip to content

Ametnes Data Service Location#

Generally, an Ametnes Data Service Location (ADSL) is a kubernetes cluster that has the Ametnes Cloud agent has to be installed and configured with a location id. It is preferable, but certainly not a requirement, that a dedicated kubernetes cluster is set assign as a data service location.

Installing the Ametnes Cloud agent.#

After selecting a kubernetes cluster to act as your Ametnes Data Service location,

  1. Add the helm repository.

    helm repo add ametnes https://ametnes.github.io/helm && helm repo update

  2. Generate a UUID on your command line with uuidgen.

    26F522B3-E412-44D0-9992-F47F03F3192B

  3. Install the Ametnes Cloud Agent and set the agent.config.location.

    helm upgrade --install --create-namespace --namespace ametnes-system ametnes-cloud-agent ametnes/cloud-agent --set agent.config.location=26F522B3-E412-44D0-9992-F47F03F3192B

Register your Ametnes Data Service location#

In your Ametnes Cloud console account, create a Data Service Location with

  1. User Supplied Id: 26F522B3-E412-44D0-9992-F47F03F3192B
  2. Name: DemoDsl
  3. Code: USE2
  4. Click Create

After a short while, the data service location should come online.

Configuring the Ametnes Cloud agent.#

The Ametnes Cloud agent expects your kubernetes cluster to be setup with;

  1. A storage class, which is used for creating persistence volumes.
  2. If nodes are tainted, the Ametnes Cloud agent must be configured to assign taints and tolerations in order to ensure service kubernetes workloads are scheduled appropriately.
  3. Permission to create kubernetes resources such as StatefulSets, Deployments, Pods, ServiceAccounts.

Storage class settings#

If no storage class configuration is supplied to the Ametnes Cloud agent, it will use the default storage class for all data services provisioned by the agent. You can supply a different storage class to the agent for all data services or for specific data services.

Global storage class setting#

To supply global storage class such as AdslEfs, update the Ametnes Cloud agent helm chart values file with 

agent:
  config:
    persistence: 
      storageClass: 'AdslEfs'

Data service specific storage class#

If you wish to supply a specific data service, such as neo4j:4.2 with a separate storage class, such as gp2, but keep other data services use the global storage class, update the Ametnes Cloud agent helm chart values file with

agent:
  config:
    persistence: 
      storageClass: 'AdslEfs'
    resources:
      service/neo4j:4.2:
        persistence: 
          storageClass: 'gp2'

Taints and Tolerations#

Global taints and tolleration setting#

You are also able to configure a specific data service, such as mysql:8.0 to run on specific nodes in your data service locationwith a separate storage class, such as gp2, but keep other data services use the global storage class, update the Ametnes Cloud agent helm chart values file with

agent:
  config:
   tolerations:
    - key: ametnes.io/role
      operator: Equal
      value: GeneralNode
      effect: NoSchedule

   affinity:
     - matchExpressions:
       - key: ametnes.io/role
         operator: In
         values:
         - GeneralNode
    resources:
      service/neo4j:4.2:
        persistence: 
          storageClass: 'gp2'

Data service specific taints and toleration#

You are also able to configure a specific data service, such as mysql:8.0 to run on specific nodes in your data service locationwith a separate storage class, such as gp2, but keep other data services use the global storage class, update the Ametnes Cloud agent helm chart values file with

agent:
  config:
   tolerations:
    - key: ametnes.io/role
      operator: Equal
      value: GeneralNode
      effect: NoSchedule

   affinity:
     - matchExpressions:
       - key: ametnes.io/role
         operator: In
         values:
         - GeneralNode
  resources:
    service/neo4j:4.2:
      tolerations:
        - key: ametnes.io/role
          operator: Equal
          value: MLNode
          effect: NoSchedule

      affinity:
        - matchExpressions:
          - key: ametnes.io/role
            operator: In
            values:
            - MLNode

Additional TLS trust CAs#

If your environment uses outbound TLS interception, configure agent.tls.trust in the Ametnes Cloud Agent Helm chart. You supply one or more additional CA certificates; the agent builds a single trusted CA bundle that includes the system roots plus those CAs, and uses the file at targetBundlePath for outbound TLS.

The chart defaults are:

  • agent.tls.trust.enabled: false — set to true when you use additional CAs or a non-default bundle path.
  • agent.tls.trust.targetBundlePath: /etc/ssl/certs/ca-certificates.crt — path to the combined CA bundle inside the agent container.

Overriding targetBundlePath#

You can override targetBundlePath when the agent image or your platform expects trusted roots at a different path (for example many RHEL- and Fedora-based images use /etc/pki/tls/certs/ca-bundle.crt instead of Debian’s default). Set it alongside your CA configuration:

agent:
  tls:
    trust:
      enabled: true
      targetBundlePath: /etc/pki/tls/certs/ca-bundle.crt
      additionalCAs:
        - crt: |
            -----BEGIN CERTIFICATE-----
            <your-interception-or-root-ca>
            -----END CERTIFICATE-----
      secret:
        create: true
        name: ""   # optional; defaults to <release>-tls-trust

Create the Secret from Helm values (one or more CAs), using the default bundle path:

agent:
  tls:
    trust:
      enabled: true
      additionalCAs:
        - crt: |
            -----BEGIN CERTIFICATE-----
            <your-interception-or-root-ca>
            -----END CERTIFICATE-----
      secret:
        create: true
        name: ""   # optional; defaults to <release>-tls-trust

Or use an existing Secret that already holds your CA certificates:

agent:
  tls:
    trust:
      enabled: true
      additionalCAs: []
      secret:
        create: false
        name: customer-ca

Proxy configuration and CA bundle environment variables#

If your network requires egress through an HTTP/HTTPS proxy, configure agent.config.proxy and set CA bundle environment variables so that the agent trusts the same certificate bundle.

This is useful when your proxy performs TLS interception and presents enterprise-issued certificates.

agent:
  extraEnvs:
    - name: REQUESTS_CA_BUNDLE
      value: "/etc/ssl/certs/ca-certificates.crt"
    - name: SSL_CERT_FILE
      value: "/etc/ssl/certs/ca-certificates.crt"
    - name: SSL_CERT_DIR
      value: "/etc/ssl/certs"

  config:
    proxy:
      enabled: true
      http: "http://proxy-host:proxy-port"
      https: "http://proxy-host:proxy-port"
      no_proxy: "127.0.0.1,localhost,.svc,.cluster.local,10.96.0.1,10.96.0.1:443,kubernetes.default.svc"
      includeLowercase: true

  tls:
    trust:
      enabled: true
      additionalCAs:
        - crt: |
            -----BEGIN CERTIFICATE-----
            <your-interception-or-root-ca>
            -----END CERTIFICATE-----
      # Optional; defaults to <release>-tls-trust
      # secret:
      #   name: ""
      # targetBundlePath: /etc/ssl/certs/ca-certificates.crt

If you maintain CA certificates outside Helm values, keep additionalCAs: [] and point secret.name to your existing Secret.

Once you have added this configuration to a file such as values-trustca.yaml, you can upgrade or install your agent with:

helm repo update
helm upgrade --install --create-namespace --namespace ametnes-system ametnes-cloud-agent ametnes/cloud-agent --set agent.config.location=<location-id> -f /path/to/values-trustca.yaml

You can now start creating resources in your kubernetes clusters such as databases, monitoring and caching services.