One place for hosting & domains


      Add CAA Records in the Linode Cloud Manager

      Updated by Linode

      Written by Linode

      Certification Authority Authorization (CAA) is a type of DNS record that allows the owner of a domain to specify which certificate authority (or authorities) are allowed to issue SSL/TLS certificates for their domain(s). This quick answer shows you how to set up CAA records on your Linode.

      Add a Single CAA Record

      1. Log in to the Linode Cloud Manager

      2. Select the Domains link in the sidebar.

      3. Select the domain you want to add the record to, or add a domain if you don’t already have one listed.

      4. Under the CAA Record section, select Add a CAA record. A form with the following fields will appear:

        Name: The subdomain you want the CAA record to cover. To apply it to your entire website (for example:, leave this field blank. To limit the record’s application to a subdomain on your site, (for example:, enter the subdomain’s name into the form field (for example: subdomain).


        • issue – Authorize the certificate authority entered in the Value field further below to issue TLS certificates for your site.

        • issuewild – Same as above, with the exception that you were issued a wildcard certificate.

        • iodef – URL where your CA can report security policy violations to you concerning certificate issue requests.

        Value: If the issue or issuewild tag was selected above, then the Value field takes the domain of your certificate issuer (for example: If the iodef tag was selected, the Value field takes a contact or submission URL (http or mailto).

        TTL (Time to Live): Time in seconds that your new CAA record will be cached by Linode’s name servers before being refreshed. The Default selection’s TTL is 300 seconds, which is fine for most cases. You can use the dig command to view the remaining time your DNS records will be cached until refreshed. Replace with your site’s domain or subdomain in the command below:

        root@debian:~# dig +nocmd +noall +answer     167 IN  A
      5. Click the Save button when finished. The CAA record should be fully propagated within the TTL duration.

      Add Multiple CAA Records

      Multiple CAA records must be added individually. If your site was issued a TLS certificate by Let’s Encrypt, but your subdomain uses a Symantec certificate, you would need two different CAA records. A reporting URL for the iodef tag would also need its own record. Those three would look something like this:

      Multiple CAA records

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.

      Source link

      An Introduction to Helm, the Package Manager for Kubernetes


      Deploying applications to Kubernetes – the powerful and popular container-orchestration system – can be complex. Setting up a single application can involve creating multiple interdependent Kubernetes resources – such as pods, services, deployments, and replicasets – each requiring you to write a detailed YAML manifest file.

      Helm is a package manager for Kubernetes that allows developers and operators to more easily package, configure, and deploy applications and services onto Kubernetes clusters.

      Helm is now an official Kubernetes project and is part of the Cloud Native Computing Foundation, a non-profit that supports open source projects in and around the Kubernetes ecosystem.

      In this article we will give an overview of Helm and the various abstractions it uses to simplify deploying applications to Kubernetes. If you are new to Kubernetes, it may be helpful to read An Introduction to Kubernetes first to familiarize yourself with the basics concepts.

      An Overview of Helm

      Most every programming language and operating system has its own package manager to help with the installation and maintenance of software. Helm provides the same basic feature set as many of the package managers you may already be familiar with, such as Debian’s apt, or Python’s pip.

      Helm can:

      • Install software.
      • Automatically install software dependencies.
      • Upgrade software.
      • Configure software deployments.
      • Fetch software packages from repositories.

      Helm provides this functionality through the following components:

      • A command line tool, helm, which provides the user interface to all Helm functionality.
      • A companion server component, tiller, that runs on your Kubernetes cluster, listens for commands from helm, and handles the configuration and deployment of software releases on the cluster.
      • The Helm packaging format, called charts.
      • An official curated charts repository with prepackaged charts for popular open-source software projects.

      We’ll investigate the charts format in more detail next.


      Helm packages are called charts, and they consist of a few YAML configuration files and some templates that are rendered into Kubernetes manifest files. Here is the basic directory structure of a chart:

      Example chart directory


      These directories and files have the following functions:

      • charts/: Manually managed chart dependencies can be placed in this directory, though it is typically better to use requirements.yaml to dynamically link dependencies.
      • templates/: This directory contains template files that are combined with configuration values (from values.yaml and the command line) and rendered into Kubernetes manifests. The templates use the Go programming language’s template format.
      • Chart.yaml: A YAML file with metadata about the chart, such as chart name and version, maintainer information, a relevant website, and search keywords.
      • LICENSE: A plaintext license for the chart.
      • A readme file with information for users of the chart.
      • requirements.yaml: A YAML file that lists the chart’s dependencies.
      • values.yaml: A YAML file of default configuration values for the chart.

      The helm command can install a chart from a local directory, or from a .tar.gz packaged version of this directory structure. These packaged charts can also be automatically downloaded and installed from chart repositories or repos.

      We’ll look at chart repositories next.

      Chart Repositories

      A Helm chart repo is a simple HTTP site that serves an index.yaml file and .tar.gz packaged charts. The helm command has subcommands available to help package charts and create the required index.yaml file. These files can be served by any web server, object storage service, or a static site host such as GitHub Pages.

      Helm comes preconfigured with a default chart repository, referred to as stable. This repo points to a Google Storage bucket at The source for the stable repo can be found in the helm/charts Git repository on GitHub.

      Alternate repos can be added with the helm repo add command. Some popular alternate repositories are:

      Whether you’re installing a chart you’ve developed locally, or one from a repo, you’ll need to configure it for your particular setup. We’ll look into configs next.

      Chart Configuration

      A chart usually comes with default configuration values in its values.yaml file. Some applications may be fully deployable with default values, but you’ll typically need to override some of the configuration to meet your needs.

      The values that are exposed for configuration are determined by the author of the chart. Some are used to configure Kubernetes primitives, and some may be passed through to the underlying container to configure the application itself.

      Here is a snippet of some example values:


        type: ClusterIP
        port: 3306

      These are options to configure a Kubernetes Service resource. You can use helm inspect values chart-name to dump all of the available configuration values for a chart.

      These values can be overridden by writing your own YAML file and using it when running helm install, or by setting options individually on the command line with the --set flag. You only need to specify those values that you want to change from the defaults.

      A Helm chart deployed with a particular configuration is called a release. We will talk about releases next.


      During the installation of a chart, Helm combines the chart’s templates with the configuration specified by the user and the defaults in value.yaml. These are rendered into Kubernetes manifests that are then deployed via the Kubernetes API. This creates a release, a specific configuration and deployment of a particular chart.

      This concept of releases is important, because you may want to deploy the same application more than once on a cluster. For instance, you may need multiple MySQL servers with different configurations.

      You also will probably want to upgrade different instances of a chart individually. Perhaps one application is ready for an updated MySQL server but another is not. With Helm, you upgrade each release individually.

      You might upgrade a release because its chart has been updated, or because you want to update the release’s configuration. Either way, each upgrade will create a new revision of a release, and Helm will allow you to easily roll back to previous revisions in case there’s an issue.

      Creating Charts

      If you can’t find an existing chart for the software you are deploying, you may want to create your own. Helm can output the scaffold of a chart directory with helm create chart-name. This will create a folder with the files and directories we discussed in the Charts section above.

      From there, you’ll want to fill out your chart’s metadata in Chart.yaml and put your Kubernetes manifest files into the templates directory. You’ll then need to extract relevant configuration variables out of your manifests and into values.yaml, then include them back into your manifest templates using the templating system.

      The helm command has many subcommands available to help you test, package, and serve your charts. For more information, please read the official Helm documentation on developing charts.


      In this article we reviewed Helm, the package manager for Kubernetes. We overviewed the Helm architecture and the individual helm and tiller components, detailed the Helm charts format, and looked at chart repositories. We also looked into how to configure a Helm chart and how configurations and charts are combined and deployed as releases on Kubernetes clusters. Finally, we touched on the basics of creating a chart when a suitable chart isn’t already available.

      For more information about Helm, take a look at the official Helm documentation. To find official charts for Helm, check out the official helm/charts Git repository on GitHub.

      Source link

      How To Install Software on Kubernetes Clusters with the Helm Package Manager


      Helm is a package manager for Kubernetes that allows developers and operators to more easily configure and deploy applications on Kubernetes clusters.

      In this tutorial we will set up Helm and use it to install, reconfigure, rollback, then delete an instance of the Kubernetes Dashboard application. The dashboard is an official web-based Kubernetes GUI.

      For a conceptual overview of Helm and its packaging ecosystem, please read our article An Introduction to Helm.


      For this tutorial you will need:

      • A Kubernetes 1.8+ cluster with role-based access control (RBAC) enabled.
      • The kubectl command-line tool installed on your local machine, configured to connect to your cluster. You can read more about installing kubectl in the official documentation.

        You can test your connectivity with the following command:

        If you see no errors, you're connected to the cluster. If you access multiple clusters with kubectl, be sure to verify that you've selected the correct cluster context:

        • kubectl config get-contexts


        CURRENT NAME CLUSTER AUTHINFO NAMESPACE * do-nyc1-k8s-example do-nyc1-k8s-example do-nyc1-k8s-example-admin docker-for-desktop docker-for-desktop-cluster docker-for-desktop

        In this example the asterisk (*) indicates that we are connected to the do-nyc1-k8s-example cluster. To switch clusters run:

        • kubectl config use-context context-name

      When you are connected to the correct cluster, continue to Step 1 to begin installing Helm.

      Step 1 — Installing Helm

      First we'll install the helm command-line utility on our local machine. Helm provides a script that handles the installation process on MacOS, Windows, or Linux.

      Change to a writable directory and download the script from Helm's GitHub repository:

      • cd /tmp
      • curl >

      Make the script executable with chmod:

      • chmod u+x

      At this point you can use your favorite text editor to open the script and inspect it to make sure it’s safe. When you are satisfied, run it:

      You may be prompted for your password. Provide it and press ENTER.


      helm installed into /usr/local/bin/helm Run 'helm init' to configure helm.

      Next we will finish the installation by installing some Helm components on our cluster.

      Step 2 — Installing Tiller

      Tiller is a companion to the helm command that runs on your cluster, receiving commands from helm and communicating directly with the Kubernetes API to do the actual work of creating and deleting resources. To give Tiller the permissions it needs to run on the cluster, we are going to make a Kubernetes serviceaccount resource.

      Note: We will bind this serviceaccount to the cluster-admin cluster role. This will give the tiller service superuser access to the cluster and allow it to install all resource types in all namespaces. This is fine for exploring Helm, but you may want a more locked-down configuration for a production Kubernetes cluster.

      Please refer to the official Helm RBAC documentation for more information on setting up different RBAC scenarios for Tiller.

      Create the tiller serviceaccount:

      • kubectl -n kube-system create serviceaccount tiller

      Next, bind the tiller serviceaccount to the cluster-admin role:

      • kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller

      Now we can run helm init, which installs Tiller on our cluster, along with some local housekeeping tasks such as downloading the stable repo details:

      • helm init --service-account tiller


      . . . Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster. Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy. For more information on securing your installation see: Happy Helming!

      To verify that Tiller is running, list the pods in thekube-system namespace:

      • kubectl get pods --namespace kube-system


      NAME READY STATUS RESTARTS AGE . . . kube-dns-64f766c69c-rm9tz 3/3 Running 0 22m kube-proxy-worker-5884 1/1 Running 1 21m kube-proxy-worker-5885 1/1 Running 1 21m kubernetes-dashboard-7dd4fc69c8-c4gwk 1/1 Running 0 22m tiller-deploy-5c688d5f9b-lccsk 1/1 Running 0 40s

      The Tiller pod name begins with the prefix tiller-deploy-.

      Now that we've installed both Helm components, we're ready to use helm to install our first application.

      Step 3 — Installing a Helm Chart

      Helm software packages are called charts. Helm comes preconfigured with a curated chart repository called stable. You can browse the available charts in their GitHub repo. We are going to install the Kubernetes Dashboard as an example.

      Use helm to install the kubernetes-dashboard package from the stable repo:

      • helm install stable/kubernetes-dashboard --name dashboard-demo


      NAME: dashboard-demo LAST DEPLOYED: Wed Aug 8 20:11:07 2018 NAMESPACE: default STATUS: DEPLOYED . . .

      Notice the NAME line, highlighted in the above example output. In this case we specified the name dashboard-demo. This is the name of our release. A Helm release is a single deployment of one chart with a specific configuration. You can deploy multiple releases of the same chart with, each with its own configuration.

      If you don't specify your own release name using --name, Helm will create a random name for you.

      We can ask Helm for a list of releases on this cluster:


      NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 1 Wed Aug 8 20:11:11 2018 DEPLOYED kubernetes-dashboard-0.7.1 default

      We can now use kubectl to verify that a new service has been deployed on the cluster:


      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE dashboard-demo-kubernetes-dashboard ClusterIP <none> 443/TCP 51s kubernetes ClusterIP <none> 443/TCP 34m

      Notice that by default the service name corresponding to our release is a combination of the Helm release name and the chart name.

      Now that we've deployed the application, let's use Helm to change its configuration and update the deployment.

      Step 4 — Updating a Release

      The helm upgrade command can be used to upgrade a release with a new or updated chart, or update the it’s configuration options.

      We're going to make a simple change to our dashboard-demo release to demonstrate the update and rollback process: we'll update the name of the dashboard service to just dashboard, instead of dashboard-demo-kubernetes-dashboard.

      The kubernetes-dashboard chart provides a fullnameOverride configuration option to control the service name. Let's run helm upgrade with this option set:

      • helm upgrade dashboard-demo stable/kubernetes-dashboard --set fullnameOverride="dashboard"

      You'll see output similar to the initial helm install step.

      Check if your Kubernetes services reflect the updated values:


      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP <none> 443/TCP 36m dashboard ClusterIP <none> 443/TCP 40s

      Our service name has been updated to the new value.

      Note: At this point you may want to actually load the Kubernetes Dashboard in your browser and check it out. To do so, first run the following command:

      This creates a proxy that lets you access remote cluster resources from your local computer. Based on the previous instructions your dashboard service is named kubernetes-dashboard and it's running in the default namespace. You may now access the dashboard at the following url:


      If necessary, substitute your own service name and namespace for the highlighted portions. Instructions for actually using the dashboard are out of scope for this tutorial, but you can read the official Kubernetes Dashboard docs for more information.

      Next we'll look at Helm's ability to roll back releases.

      Step 5 — Rolling Back a Release

      When we updated our dashboard-demo release in the previous step, we created a second revision of the release. Helm retains all the details of previous releases in case you need to roll back to a prior configuration or chart.

      Use helm list to inspect the release again:


      NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 2 Wed Aug 8 20:13:15 2018 DEPLOYED kubernetes-dashboard-0.7.1 default

      The REVISION column tells us that this is now the second revision.

      Use helm rollback to roll back to the first revision:

      • helm rollback dashboard-demo 1

      You should see the following output, indicating that the rollback succeeded:


      Rollback was a success! Happy Helming!

      At this point, if you run kubectl get services again, you will notice that the service name has changed back to its previous value. Helm has re-deployed the application with revision 1's configuration.

      Next we'll look into deleting releases with Helm.

      Step 6 — Deleting a Release

      Helm releases can be deleted with the helm delete command:

      • helm delete dashboard-demo


      release "dashboard-demo" deleted

      Though the release has been deleted and the dashboard application is no longer running, Helm saves all the revision information in case you want to re-deploy the release. If you tried to helm install a new dashboard-demo release right now, you'd get an error:

      Error: a release named dashboard-demo already exists.

      If you use the --deleted flag to list your deleted releases, you'll see that the release is still around:


      NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 3 Wed Aug 8 20:15:21 2018 DELETED kubernetes-dashboard-0.7.1 default

      To really delete the release and purge all old revisions, use the --purge flag with the helm delete command:

      • helm delete dashboard-demo --purge

      Now the release has been truly deleted, and you can reuse the release name.


      In this tutorial we installed the helm command-line tool and its tiller companion service. We also explored installing, upgrading, rolling back, and deleting Helm charts and releases.

      For more information about Helm and Helm charts, please see the official Helm documentation.

      Source link