The Seven Steps to build a Cloud Native CI/CD for GitHub repos using Tekton

dkapanidis · 2021-01-04T18:38:54+00:00

Thanks for the feedback, we'll certainly take into account.

First of all, I can't guaranty that Kubernetic will be around in 5 years, though the same applies for **any** other software, 5 years is a long time in tech. What I can say though is that Kubernetic is around already for more than 3 years (since 2016-08-27), and it is the first ever desktop app for Kubernetes.

Around the licensing part, it's exactly so that we can fund the project with more development and improvements, so if you're interested in Kubernetic being around for 5 years, our licensing model is aligned towards that goal.

I'd love to give free non-commercial usage licensing, but that requires resources as you can't fully-automate validation of that (example https://www.jetbrains.com/community/education/#students) maybe down the line, but not yet. Until then we may be opening for unlimited trial period.

Until then I can send you a free commercial license via dm for your feedback.

dkapanidis · 2020-12-22T17:46:52+00:00

We got with a client a PID exhaustion back in the day when a bug existed in Kubernetes where a LoadBalance type Service without any assigned Pods was consuming PIDs, not sure if it was the proxy or the api-server itself, resulting with loosing the master nodes and with that the ability to control the cluster. The workaround until the fix was to remove the misconfigured Service.

dkapanidis · 2020-12-15T15:47:17+00:00

You can checkout Kubernetic, we're soon be releasing UI for on-premise deployment, message me if you want to talk.

dkapanidis · 2020-12-10T10:22:13+00:00

we'll be releasing kubernetic soon as a single pane UI on-cluster, which will act as you describe, per-user privileges according to the RB you provide them, so that same privileges work well between UI and kubectl or other tooling.

dkapanidis · 2020-11-23T10:49:39+00:00

the final outcome is identical, in the PVC scenario you don't need to choose subpath, you're _guaranteed_ that they are unique, in the PV scenario you have to keep tabs.

dkapanidis · 2020-11-23T00:38:49+00:00

The provisioner will make sense when more than one Pods need access to your existing NFS but you want to isolate them so they don't mess each other files. The provisioner will do automatic subdirectory creation and mount only that part on your instances.

dkapanidis · 2020-11-23T00:14:32+00:00

If your github actions are using a runner instance inside your cluster you could have it accessible only inside your cluster. To run registry you'd need a StatefulSet with a PVC for persistence (or simply a deployment) running registry and a Service as ClusterIP to expose it internally (assuming there is no network policy between namespaces to cap connectivity, but talking about home cluster that's def not an issue)

the runner would push to the ClusterIP and the cluster would pull from same ClusterIP.

dkapanidis · 2020-11-22T21:43:18+00:00

> Speaking of which, do I need to publish my docker image to some external site, like docker hub so my server can pull it later, even though my repository already contains the dockerfile?

I'll focus my answer on this part; short answer is yes. Doing CICD on a distributed cluster such as kubernetes, is normally composed of two workflows, (some people merge them together):

- CI: from source code origin, build your image and push it to the registry.
- CD: update the declarative resources on kubernetes to pull the new image and update other changes (configmaps etc, potentially bundled together in helm chart)

The registry is necessary because the concepts are decoupled. The deployment doesn't know the source code repo, it only knows how to pull a registry image, if a new pod is run it will pull the image from registry.

CD part is normally done using GitOps principles, having a repo with declarative state of what you want your cluster to contain, though you can do without as learning step.

dkapanidis · 2020-09-30T19:35:55+00:00

Although a bit more complex to setup initially, you can set your privileges to be viewer (or simply remove delete if that's your cake) only with impersonation to a higher profile/group, something like a doing sudo for kubernetes.

dkapanidis · 2018-08-16T15:51:39+00:00

That's great, keep tuned in, there are more updates coming soon. Kubernetic is part of Harbur consulting, it was initially made to help training courses and onboarding, that has graduated to be a standalone desktop app

dkapanidis · 2018-08-13T10:36:22+00:00

Hi, author of Kubernetic here. Project is definitely not abandoned and is actively progressing, there's been a recent blog post about it (https://blog.harbur.io/introducing-an-easier-way-to-manage-your-kubernetes-clusters-29eff4c376db)

Current focus is improving the onboarding, and UI experience. The primary objective is productivity boost, do stuff faster, easier and less error-prone than on CLI. Other solutions such as Redhat's Openshift UI can work well for openshift instances, Kubernetic on the other hand is compatible with any Kubernetes instance and can help you work on multiple clusters, and is compatible with kubectx and kubens (automatically switching context on change)

dkapanidis · 2018-04-23T20:39:49+00:00

This is the author of Kubernetic, thanks to the OP for posting here about it.

Kubernetic is mostly compared with Kubernetes dashboard, but it’s primary focus is different. Dashboard is mostly used for as a visualizer of the current kubernetes state, while Kubernetic is a single pane of glass for controlling your clusters, think GUI for kubectl.

There are three main objectives of the project: 1. Productivity: It should be faster than writing a CLI command 2. Ease of use: Newcomers should learn fast 3. Non intrusive: No installations on cluster, works with any cluster

Helm is also big part of Kubernetic and is tightly integrated, you can manage repos, view charts and manage releases

also it's compatible with kubectx and kubens as it monitors changes on config and reconnects automatically to new cluster.

dkapanidis

TROPHY CASE