new post: private cluster, Argo CD and inlets PRO #26
Conversation
jsiebens
force-pushed
the
post_argocd_inlets
branch
from
9137968 to
8e1bb06
Compare
|
|
||
| The biggest challenge lies in the communication between Argo CD and the Kubernetes API services of your highly secured private clusters. | ||
|
|
||
|  |
There was a problem hiding this comment.
DOK should be DOKS, or perhaps "Kubernetes on Digital Ocean"?
Could you centralise the image too.
|
I noticed the term "CI/CD cluster", but I think there might be a less confusing term. ArgoCD just does CD, and it's likely CI would be done somewhere else like Google Cloud Build or GitHub Actions. How about the term "Control cluster" or "Central cluster", or even better "Management cluster"? Then that terminology should be used consistently across the doc and also in the diagram(s) |
|
|
||
| Two of the most popular open-source projects for GitOps are Flux, which was created at Weaveworks. Intuit, an American payroll company, created Argo CD. Both projects were donated to the Cloud Computing Foundation (CNCF) to encourage broader use and contributions. | ||
|
|
||
| Like our [monitoring use case](https://inlets.dev/blog/2020/12/15/multi-cluster-monitoring.html), there are many reasons you may have multiple Kubernetes clusters where you want to deploy applications on with the GitOps way of working. Even more, some of the target clusters may be running in a tightly controlled private network. |
There was a problem hiding this comment.
I like the term "target cluster" - that works very well with "management cluster" being the opposite term.
|
|
||
| In this post, you'll learn how to apply GitOps on multiple private Kubernetes cluster with a single Argo CD installation. | ||
|
|
||
| ## Continuous Deployment on Kubernetes with GitOps |
There was a problem hiding this comment.
This whole section is a lot for a reader to get through.
What if you started with a brief introduction about what the reader will get in some bullets before going into depth about GitOps?
| EOF | ||
| ``` | ||
|
|
||
| > This example is creates a client with a single yaml configuration. There is also an Helm [chart](https://github.com/inlets/inlets-pro/tree/master/chart/inlets-pro-client) available for advanced usages. |
There was a problem hiding this comment.
A helm chart is also provided for the inlets-pro client for easy configuration.
|
|
||
| ## Adding the cluster to Argo CD | ||
|
|
||
| With the tunnel up and running, we can now register the private cluster to Argo CD. |
There was a problem hiding this comment.
The terminology used earlier was "target cluster"
|
|
||
| Typically you could add a cluster using the Argo CD CLI command `argocd cluster add CONTEXTNAME`, where the context name is a context available in your current kubectl config. That command installs a ServiceAccount (`argocd-manager`) into the `kube-system` namespace of that kubectl context, and binds the service account to an admin-level ClusterRole. | ||
|
|
||
| Unfortunately, adding a cluster this way will fail in our scenario. Besides creating the service account in the target cluster, the command will also try to register the cluster in Argo CD with the endpoint in your context and will validate if Argo CD can communicate with the API service. It should be obvious the latter will not succeed. |
There was a problem hiding this comment.
Just as a note: Unfortunately, adding a cluster this way will fail in our scenario. - I managed to get it working this way, with the inlets-client and also with your hosts file workaround.
There was a problem hiding this comment.
It should be obvious the latter will not succeed. - I would remove that
|
|
||
| Unfortunately, adding a cluster this way will fail in our scenario. Besides creating the service account in the target cluster, the command will also try to register the cluster in Argo CD with the endpoint in your context and will validate if Argo CD can communicate with the API service. It should be obvious the latter will not succeed. | ||
|
|
||
| Luckily for us, we can configure everything in a declarative way. |
There was a problem hiding this comment.
We can simulate the steps that the CLI takes to onboard a new cluster. (Insert brief summary of the steps that will follow)
Signed-off-by: Johan Siebens <johan.siebens@gmail.com>
jsiebens
force-pushed
the
post_argocd_inlets
branch
from
8e1bb06 to
14f3e0a
Compare
* Minor edits to the introduction, added links and changed the date to June. * Closes: #26 Signed-off-by: Johan Siebens <johan.siebens@gmail.com> Signed-off-by: Alex Ellis (OpenFaaS Ltd) <alexellis2@gmail.com>
* Minor edits to the introduction, added links and changed the date to June. * Closes: #26 Signed-off-by: Johan Siebens <johan.siebens@gmail.com> Signed-off-by: Alex Ellis (OpenFaaS Ltd) <alexellis2@gmail.com>
2 participants
Signed-off-by: Johan Siebens johan.siebens@gmail.com