You know the drill. Create a new cluster or reuse the one you dedicated to the exercises.
First, we'll go to the local copy of the vfarcic/k8s-specs repository and make sure that we have the latest revision. Who knows? I might have changed something since you read the last chapter.
1 cd k8s-specs
2 3 git pull
The requirements for the cluster are now slightly different. We'll need Helm server (tiller). On top of that, if you are a minishift user, you'll need a cluster with 4 GB RAM.
For your convenience, the new Gists and the specs are available.
- docker4mac-helm.sh: Docker for Mac with 3 CPUs, 3 GB RAM, with nginx Ingress, and with tiller (https://gist.github.com/vfarcic/7e6b068c6d3d56fc53416ac2cd4086e3).
- minikube-helm.sh: minikube with 3 CPUs, 3 GB RAM, with ingress, storage-provisioner, and default-storageclass addons enabled, and with tiller (https://gist.github.com/vfarcic/728246d8be349ffb52770f72c39e9564).
- kops-helm.sh: kops in AWS with 3 t2.small masters and 2 t2.medium nodes spread in three availability zones, with nginx Ingress, and with tiller. The Gist assumes that the prerequisites are set through Appendix B (https://gist.github.com/vfarcic/6c1ebd59305fba9eb0102a5a8cea863).
- minishift-helm.sh: minishift with 3 CPUs, 3 GB RAM, with version 1.16+, and with tiller (https://gist.github.com/vfarcic/945ab1e68afa9e49f85cec3bc6df4959).
- gke-helm.sh: Google Kubernetes Engine (GKE) with 3 n1-highcpu-2 (2 CPUs, 1.8 GB RAM) nodes (one in each zone), and with nginx Ingress controller running on top of the "standard" one that comes with GKE, and with tiller. We'll use nginx Ingress for compatibility with other platforms. Feel free to modify the YAML files and Helm Charts if you prefer NOT to install nginx Ingress (https://gist.github.com/vfarcic/1593ed36c4b768a462b1a32d5400649b).
- eks-helm.sh: Elastic Kubernetes Service (EKS) with 2 t2.medium nodes, with nginx Ingress controller, with a default StorageClass, and with tiller (https://gist.github.com/vfarcic/6de44c440c0d0facb20b743c079bd12f).
Besides creating a cluster, we'll need an IP through which we can access it. The instructions that follow differ from one Kubernetes flavor to another. Please make sure you execute those matching your cluster.
If your cluster is running in AWS and if it was created with kops, we'll retrieve the IP by digging the hostname of the Elastic Load Balancer (ELB). Please execute the commands that follow.
1 LB_HOST=$(kubectl -n kube-ingress
2 get svc ingress-nginx
3 -o jsonpath="{.status.loadBalancer.ingress[0].hostname}")
4
5 LB_IP="$(dig +short $LB_HOST
6 | tail -n 1)"
If your cluster is running in AWS and if it was created as EKS, we'll retrieve the IP by digging the hostname of the ELB. Please execute the commands that follow.
1 LB_HOST=$(kubectl -n ingress-nginx
2 get svc ingress-nginx
3 -o jsonpath="{.status.loadBalancer.ingress[0].hostname}")
4
5 LB_IP="$(dig +short $LB_HOST
6 | tail -n 1)"
If you're using Docker for Mac or Windows, the cluster is accessible through localhost. Since we need an IP, we'll use 127.0.0.1 instead. Please execute the command that follows.
1 LB_IP="127.0.0.1"
Minikube users can retrieve the IP through minikube ip. If you are one of them, please execute the command that follows.
1 LB_IP=$(minikube ip)
Retrieving IP from minishift is similar to minikube. If that's your Kubernetes flavor, please execute the command that follows.
1 LB_IP=$(minishift ip)
Finally, if you are using GKE, the IP we're looking for is available through the ingress-nginx service. Please execute the command that follows.
1 LB_IP=$(kubectl -n ingress-nginx
2 get svc ingress-nginx
3 -o jsonpath="{.status.loadBalancer.ingress[0].ip}")
No matter how you retrieved the IP of your cluster, we'll validate it by echoing the LB_IP variable.
1 echo $LB_IP
The output will differ from one case to another. In my case, it is 52.15.140.221.
There's only one more thing left before we jump into Chart repositories. We'll merge your fork of the go-demo-3 code repository with the origin and thus ensure that you are up-to-date with changes I might have made in the meantime.
First, we'll move into the fork's directory.
1 cd ../go-demo-3
To be on the safe side, we'll push the changes you might have made in the previous chapter, and then we'll sync your fork with the upstream repository. That way, we'll guarantee that you have all the changes I might have made.
You probably already know how to push your changes and how to sync with the upstream repository. In case you don't, the commands are as follows.
1 git add .
2 3 git commit -m 4 "Packaging Kubernetes Applications chapter"
5 6 git push
7 8 git remote add upstream 9 https://github.com/vfarcic/go-demo-3.git
10 11 git fetch upstream
12 13 git checkout master
14 15 git merge upstream/master
We pushed the changes we made in the previous chapter, we fetched the upstream repository vfarcic/go-demo-3, and we merged the latest code from it. The only thing left is to go back to the k8s-specs directory.
1 cd ../k8s-specs
Now we are ready to explore Helm repositories with ChartMuseum.