Video

Should I create a kubeconfig.yaml file in the crossplane-tutorial directory ?

Yes. That's what the setup script is doing.

Pick a time from calendar.app.google/MRbyC9Q44DUF4bWZ9 and we can go through it together.

@@DevOpsToolkit Hi Victor , I cant thank you enough for this. I have blocked some time for us on the 17th . but meanwhile , i want to unblock myself . is there a forum I can post my question with whatever error I am getting ?

@anupamojha1896 looking forward to the chat. In the meantime, crossplane slack is probably the best place to get a quick answer. I'm there under vfarcic (but can't guarantee when I'll answer).

otomi.io is out there as well.

Us that a kcp addon for kubectl? I did not even know it exists.

There's fluentd and fluentbit for shipping logs.

@@DevOpsToolkit Thanks. I mean more on the storage side. Like if I want to move away from AWS open search to decrease cost. Are there any alternatives than Loki?

@AhmedAyman-gs7oz Loki is the only one I used besides elasticsearch (excluding managed solutions).

I'm planning to release a video that explores different types of scaling on July 8.

I have no doubt that YAML is the best format to define state that is passed to an API. When tasks are concerned I am not 100% sure. Also, YAML being a great format to define something does not necessarily mean that we have to write it directly. I, for example, tend to use KCL that outputs YAML I need.

Fair point! Same is applicable to _make_. Having said that - task and just are statically compiled binaries. At worst they can be part of the repo.

There are always things that need to be installed. I tend to use devbox for that.

@@DevOpsToolkit Indeed; thank's for sharing GitHub repo - it's all there

@Jarek. oh, does make only get installed with the base-devel packages on Ubuntu? If that's the case maybe my point has no merit

@@DevOpsToolkit I'm a bit old fashioned guy. I prefer building a Docker image with all the tools needed. The advantage is that image can be used in CI/CD as well. Reproducible environment for everyone, including automation.

I'd rather use Taskfile, for yaml format and additional features.

by default it creates PRs.

I feel that kyverno grew in the meantime abd that if i would do a comparison it would be a very short one: "manage stuff with kubernetes, use kyverno for policies. There is no alternative."

Thereight be tools that do that, but I never looked for them. I just execute yq inside pipelines and push changes back to git.

I tend to use argo CD or flux for that. You'll find quite a few videos with those on this channel.

@DevOpsToolkit today interviewer asked me " how do u upgrade helm using automation or have i ever used cicd for upgrading helm " , i prefer argocd tbh , i introduced argocd in my previous organizations as well.

@TeresaShellvin essentially, you just need to change the tag in values.yaml and push changes back to git. From there on, either argo CD does the job or, if you're not using it, helm upgrade does the trick.

@@DevOpsToolkit awesome , thank u so much

Kubernetes is based on controllers that perform some operations. Those operations can be anything. The controller that managed pods does that by talking to container runtime that spins up containers. Those are inside the cluster. Ingress controller manages external load balancers. Those are outside the cluster. Persistent volumes are storage also outside cluster that get attached to containers or nodes. Hence, there are quite a few examples of using kubernetes to manage resources both inside and outside itself. Now, given that controll can be anything and manage anything, it all depends on which controllers you install. Ingress, for example, is not baked into kubernetes.you need to install it. Similarly, if you install kubevirt, cluster api, crossplane, or almost anything else in kubernetes, you get more controllers that do something and all those i just mentioned manage resources outside the cluster. Search for crossplane on this channel and you'll see quite a few videos, all of them showing how to extend kubernetes with Crossplane with the goal to use it as a control plane to manage resources elsewhere.

I now got what you mean. Thanks for your prompt reply and explanation!

I agree that you should not remove those. You need a tool that translates code to API requests. What you might be missing is a way to build your own APIs.

I'm not sure I'll do harness. It's a tool of the past that is not adopted by many these days and is typically used by those who adopted it a while ago.

I'm not sure I understood your question. Do you mean that you do not need to manage kubernetes clusters with Crossplane (but some other type of resources)?

@@DevOpsToolkit yeah... Imagine if we didn't use k8s at all... And we wanted a control Plane trat can translate and do a drift detection between JSON for Devs... And Terraform CDK Pulumi that we use to actually manage Cloud APIs... Would CrossPlane work for that?

@matscloud why not use kubernetes? Before you answer that question, let me stress out that kubernetes is not used only as a platform to run apps packaged as container images. Even if you do not rin your apps in kubernetes you can still use kubernetes for many other things. That can be for control planes like those enabled by crossplane, for managing virtual machines with kubevirt, for running ci/CD pipelines, etc. As for continuous drift detection and reconciliation... We saw that the only reasonable way to do that is by performing it in individual resources and not projects as a whole. If you prefer terraform or a similar tool you would first need to break projects into individual resources and then do continuous drift detection and reconciliation on each of them. Not using kubernetes for that would be silly since that's hard to do and is already baked into kubernetes. What you can do (apart from breaking projects into resources) is create some sort of kubernetes operatora for terraform or whatever you're using. What I'm trying to say is not whether to use terraform or something else but, rather, that ignoring kubernetes would be a waste since it already comes with many important features baked into it. Use it to create APIs and to manage resources of any kind whereever they are. Know, whether what's managing those resources inside kubernetes is based on terraform, pulumi, crossplane, kubevirt, or anything else is of secondary importance. When we get a kubernetes controller that does something we stop caring what is powering such a controller.

@matscloud I forgot to comment on APIs. When I talk about them, I assume that you use to manage Cloud APIs. I was referring to your APIs. If you want to enable devs to do something, give them APIs to do that. Do not give them files and CLIs. Now, the only reasonable way to create APIs today (at least when managing resources is concerned) is by creating kubernetes CRDs. There are plenty of ways to do that.

Talos is great but I'm not sure how it fits into the context of this video.

It's more of a combination of Json and Go.

In theory, GitOps can be done outside Kubernets. In practice, as far as I know, no one built such a solution. Many say they did but those can be easily verified by asking them whether such solutions implement all four GitOps principles (opengitops.dev). The truth is that Kubernetes has quite a few baked-in capabilities that make GitOps much easier to implement. That's probably the reason why we don't see it outside Kubernetes. P.S. We had GitOps long time ago with Chef and Puppet (except that it was more like SvnOps) but those died in the meantime.

@@DevOpsToolkit that's what I meant. I hear many saying: I do GitOps because I use Terraform but I don't think they catch the difference! Thanks for the clarification

It does not matter what you do in all the stages but the last. Build binaries, run tests, etc. If possible, the last stage should be based on scretch image. If that's not an option, use chainguard, alpine, or busybox as the base image of the last stage. Inside that stage, add only things that are needed (e.g. the binary) abd nothing else. As for your question... Multi stage builds are not really about optimization. The final stage is the image and those before it are just a convenient way to do something inside docker as opposed doing it outside. If, for example, you compile the binary outside docker and just add it to the image the end result will be the same.

@@DevOpsToolkit Thanks for taking time to answer. You are a gem. Just one thought again on same point - would you prefer to run the optimization (as mentioned above) in previous layers or developers should choose bulky image to finish the work and then always use lighter image for the final stage.

@RVRead I think that the two options you described are the same (or I misunderstood). You can use any image of any size in previous layers, assuming that by previous layers you mean previous stages. As long as the last stage is based on no image or a very small image you should be fine. What happens before the last stage is not that important.

@@DevOpsToolkit Thanks again for your expert opinion and kind response. Yes I was pointing to previous layers and now its clear to me :)

Which project?