0
votes

I am implementing the continuous integration and continuous deployment by using Ansible, Docker, Jenkins and Kubernetes. I already created one Kubernetes cluster with 1 master and 2 worker nodes by using Ansible and kubespray deployment. And I have 30 - 40 number of micro service application. I need to create that much of service and deployments.

My Confusion

When I am using Kubernetes package manager Kubernetes Helm chart, then do I need to initiate my chart on master node or in my base machine from where I I deployed my kubernet cluster ?

  1. If I am initiating inside master, then can I use kubectl to deploy using ssh on remote worker nodes?
  2. If I am initiating outside the Kubernetes cluster nodes , then Can i use kubectl command to deploy in Kubernetes cluster ?
2
I think so you need to run the helm charts where helm will be installed. mostly it will be on master. the deployment in k8s is done on the worker nodes using the deployment file. since the worker nodes are configured you don't need to worry on the deployment k8s will take care of that for you - error404

2 Answers

3
votes

Your confusion seems to lie in the configuration and interactions of Helm components. This explanation provides a good graphics to represent the relationships.

If you are using the traditional Helm/Tiller configuration, Helm will be installed locally on your machine and, assuming you have the correct kubectl configuration, you can "initialize" your cluster by running helm init to install Tiller into your cluster. Tiller will run as a deployment in kube-system, and has the RBAC privileges to create/modify/delete/view the chart resources. Helm will automatically manage all the API objects for you, and the kube-scheduler will schedule the pods to all your nodes accordingly. You should not be directly interacting with your master and nodes via your console.

In either configuration, you would always be making the Helm deployment from your local machine with a kubectl access to your cluster.

Hope this helps!

1
votes

If you look for the way for running helm client inside your Kubernetes cluster, please check the concept of Helm-Operator.

I would recommend you also to look around for term "GitOps" - set of practices which combines Git with Kubernetes, and sets Git as a source of truth for your declarative infrastructure and applications.

There are two great OSS projects out there, that implements GitOps best practices:

  • flux (uses Helm-Operator)
  • Jenkins-x (uses helm as a part of release pipeline, check out this session on YT to see it in action)