• Developer Tooling for Kubernetes in 2021: Helm, Kustomize, and Skaffold
  • Liran Haimovitch
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: kamly
  • Proofread: PassionPenguin, Greycodee, lsvih

Developer tools for Kubernetes 2021: Helm, Kustomize and Skaffold

Over the past few years, we’ve seen a plethora of tools emerge in the Kubernetes ecosystem to enable simpler software development (which is very rare). As often happens in an evolving ecosystem, some tools evolve and adapt, while others are discarded, or at least incorporated into new products. What better way to start 2021 than with a fresh look at the options we have?

In this series of blogs, I’ll cover the various developer tools currently available in Kubernetes and their functionality in the development workflow, and most importantly, I’ll cover the important news about each tool. In this article, I’ll focus on the tools used to define our Kubernetes application. They are Helm, Kustomize and Skaffold.

Kubernetes List (YAMLs)

If you are new to Kubernetes, I recommend reading this introduction because I find it quite in-depth. For our purposes, the most important thing to know is that Kubernetes has a declarative way of orchestrating services. You write the required state for your service in YAML format in some configuration files called “checklists” and send them to Kubernetes to implement that state.

Helm

Helm is the king! It is the standard for packaging, sharing, and deploying K8S services. We can think of Helm as a package manager — it allows you to combine multiple pieces of YAML configuration into a single installation package called Chart in a consistent and structured way.

As the author of the installation package, creating Helm Chart has significant benefits for you:

  1. You can use custom parameters to make your service configurable at deployment time. To do this, you need to use templates.
  2. You can publish services to private or public repositories in versioned and traceable ways.
  3. You can make your service dependent on another Helm Chart.
  4. Overall, Helm provides you with powerful encapsulation capabilities to ensure that your services are deployed as expected.

As a user of the installation package, installing Helm Chart gives you more:

  1. You can use open source available Charts and organize your own proprietary charts.
  2. You can customize the service according to the Settings provided by the installation package author.
  3. You have a real version source to deploy the installer.
  4. You don’t have to worry about the complexity of the Kubernetes specification language.
  5. The Helm supports atomic operations to minimize risks to services and clusters.
  6. Overall, you get a service installation package that is easy to understand and ready to use.

What’s new at Helm?

At the end of 2019, we saw the release of Helm version V3, involving the removal of cluster side components (Tiller) and a host of other features. By the end of 2020, Helm V2 had been scrapped and most of the public Chart had migrated to v3 format. If you are still using Helm V2, be sure to allocate time to upgrade your recent roadmap (it may be helpful to look at this plugin while you are upgrading).

Over the past few releases, the Helm team has been busy addressing one of the biggest complaints of Helm users — the difficulty of using YAML templates. Helm now has a powerful linting command, which should be your new choice when debugging pesky YAML problems.

Another nice addition to Helm is post rendering, which allows you to customize Helm Chart using tools like Kustomize.

Last but not least, 2020 will also see a shift to a more decentralized chart management approach and the launch of two central repositories that share Chart:

  1. CNCF ArtifactHub.
  2. ChartCenter for JFrog (check out Rookout team member Josh’s webinar for more information).

Kustomize

The biggest disadvantage of Helm is that the customization of services is limited to pre-existing configuration options. Not only that, chart authors must also implement these customization options in a somewhat cumbersome templating way. To solve this problem, Kustomize comes in.

Kustomize allows you to build Kubernetes services as a series of layers and patches, enabling unlimited customization. Kustomize uses the YamL-based Kubernetes-Aware patch format to add/remove/update any portion of the list of services. Kustomize became an integral part of Kubectl in version 1.14. All you have to do is execute kubectl -k to call it. The documentation is not complete, but the official presentation and this blog post will give you some idea.

Kustomize is a powerful tool that allows you to modify services in Kubernetes in any way. Unfortunately, this also means that the learning curve can be quite steep. Arbitrary customization also means an increased likelihood of misconfiguring the service. An advanced use case for Kustomize is to use Helm’s post-rendering capabilities to patch an existing Helm Chart without forks, in the hope of making version upgrades seamless.

What’s new with Kustomize?

Many tools within the Kubernetes ecosystem embed Kustomize, adding its functionality to their own tools. The most prominent examples are orchestration and continuous deployment tools such as ArgoCD, Flux, and Kubestack. If you are searching for a patch feature like Kustomize, check out your CD (continuous deployment) tool and you may find it there.

If you are as unfamiliar as I am with the Kubernetes build process, you may not know that the maintainer has frozen the version of Kustomize embedded in Kubectl at 2.0.3 during the initial integration. In addition to making the documentation even messier, this means that versions within Kubectl are missing a number of enhancements made over the past two years. The team is making significant progress on the re-integration and hopefully they can resolve this issue soon. In the meantime, if you need the latest version, consider using Kustomize as a standalone CLI tool.

Skaffold

Skaffold takes a different approach, following DevOps best practices and maintaining consistency in development environments and workflows across the SDLC. Skaffold builds and deploys Kubernetes services for development workflows, continuous integration (CI), and continuous deployment (CD).

For builds, Skaffold can use Dockerfile, Buildpacks, Bazel, and even custom scripts (more on building container images in an upcoming blog post!). ! For deployment, Skaffold includes its limited templating engine and can call kubectl, Helm, or Kustomize.

Skaffold has three main modes of operation:

  1. Skaffold dev – This runs Skaffold in a monitor, build, deploy cycle. In this mode, you can edit source files locally and Skaffold will deploy them to the cluster of your choice. Skaffold supports port forwarding and log tracing, providing a smoother development experience when working in this mode.
  2. Skaffold Build – This will run Skaffold once to build your artifacts and push them to the repository of your choice.
  3. Skaffold deploy — This will deploy the service you build to a cluster of your choice, possibly using Helm or Kustomize to perform this operation. If you want to build and deploy using a single command, you can choose Skaffold Run.

What’s new at Skaffold?

In 2020, the Skaffold team focused on making projects easier to adapt to various workflows and more interoperable with other tools. Some of these improvements include more flexible integration of CI/CD and GitOps, and better support for Python and Java.

In addition, Skaffold now has a new beta mode of operation – Skaffold Debug. In this mode, Skaffold tries to automatically configure the service runtime for remote debugging. While this is a nice feature, using traditional debuggers in a microservice environment is tricky at best, especially when using remote clusters. If you have problems with this, we strongly recommend you check out Rookout’s non-breaking debugger.

conclusion

We’ve seen significant market integration when it comes to packaging, deploying, and sharing the vexing Kubernetes service list. CNCF (Cloud Native Shared Foundation) is now home to the main tools, of which Helm is an official CNCF project and Kustomize is integrated into Kubectl and many other tools. As with many other parts of the Kubernetes ecosystem, the tools here are very mature, and each tool has a clear purpose.

We can use Helm to package, share, and install defined Kubernetes services; Use Kustomize to patch existing Kubernetes services. As for Skaffold? It’s a useful tool (and it’s popular!). But configuring the Kubernetes service is not its primary purpose.

I hope you found this short guide useful — please don’t hesitate to share your feedback with me and let me know of any other topics you’d like me to cover.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.