Configuring access for Kubectl to private GKE cluster
A guide to how to configure access for Kubectl to private Google Kubernetes Engine cluster with different level of restricted access
How does the Armory Halyard installer work? What makes it different from the standard OSS Spinnaker installer?
Also, does it use Terraform? Does it run as a single Docker container?
First, a bit of background. Spinnaker is composed of a numnber of microservices (primarily Spring Java-based), that often run as Docker containers in a Kubernetes cluster.
The OSS Halyard installer works roughly as follows†:
halcommand (locally on your machine, in a container, or on a VM) to start up a Halyard daemon, which you then interact with and which also interacts with your Spinnaker cluster
halcommands to tell the daemon how to create/update your ‘halconfig’, which is a codified definition of your Spinnaker cluster. For example, in order to set up a basic Spinnaker cluster, you’d need several of the following:
hal config provider kubernetes enableto enable the Kubernetes Cloud Provider
hal config provider kubernetes account add X --<flags>to add a Kubernetes account
hal config storage edit --<flags>to configure persistent storage using some blob storage
hal config deploy edit --type distributed --account-name X --<flags>to configure Halyard to deploy Spinnaker as a distributed set of Kuberntes deployments on account X
hal configare added to a dot directory called
.hal. For example, most of the above configurations would be reflected in
hal deploy applyto ‘apply’ all of the changes that you’ve made and install Spinnaker to your cluster. This does the following:
Then, you’d add additional cloud providers (again, via
hal config), and apply them to your cluster with
hal deploy apply, which create corresponding secrets and configurations which would then get updated on your deployments.
†This is greatly simplified, but should provide enough background to understand what’s going on.
The Armory Halyard installer is an extension of the OSS Halyard installer. We make the initial deployment of Spinnaker much simpler if you’re working with a Kubernetes cluster and AWS S3, by adding a command that triggers a series of prompts (sort of a mini tutorial) that handles a lot of the initial configuration. This occurs when you run
hal armory init - it will prompt you for the following information:
So with the Armory Halyard installer, we make it much easier to get your initial Spinnaker up and running by automating a lot of the initial configuration.
Therefore - the Armory Spinnaker distribution does not currently use Terraform to get up and running; it basically relies on a bunch of user provided configuration to deploy a number of Kubernetes manifests to create the mulitple microservices that comprise Spinnaker.
It’s not a single Docker container, and it’s not a set of static VMs - it’s a highly-resilient distributed microservices architecture that runs on top of Kubernetes.
Here are a couple key points:
If you already have a Kubernetes cluster, and you already have access to S3, we make installing Spinnaker insanely easy - just run our installation script, and you can have Spinnaker up and running in 15 minutes or less.
If you’re not using S3 or not using Kubernetes, you can still get all the other benefits of the Armory distribution, just by following the standard OSS
hal configuration steps using our extended Halyard package.
Either way, feel free to reach out to us at firstname.lastname@example.org and we can help you get started!