Use CNCF’s open source tools in conjunction with Kubernetes Cloud Native Buildpacks and Carvel Suite
The Cloud Native Computing Foundation provides various tools and frameworks to develop cloud – and container-based apps and microservices. We show two well-known solutions.
Companies on the topic
With the Carvel Suite, cloud-native developers get a number of Kubernetes – enabled tools-or, if necessary, just a few.
(Picture: Carvel.dev)
Anyone who is involved in the development of microservices, containers and Kubernetes may be familiar with some tools from the Cloud Native Computing Foundation (CNCF). In addition to frameworks and tools for development, the CNCF also provides numerous open source solutions for the management of container and microservices environments.
Known projects of the CNCF are, for example, Kubernetes, Istio and Linkerd. In this post, we highlight the Cloud Native buildpacks used to create OCI images for applications, as well as the Carvel Suite. The Carvel Suite is a collection of tools that all perform a single task. The various tools can be used to package and deploy applications in Kubernetes clusters.
Cloud Native Buildpacks – Pack application as OCI images
The Cloud Native Buildpacks have been a project of the Cloud Native Computing Foundation since 2018. The buildpacks fully support the OCI format and allow the creation of packages based on an OCI image for new applications. Buildpacks therefore create OCI-compliant containers from program code. These containers can be made available on various platforms.
The buildpacks provide similar functionality to Dockerfiles, so they allow you to pack container images for deployment. It makes sense to use it primarily for packaging applications as a container image. This ensures that your application in the container works as planned on all platforms.
The image includes the base image, version, dependencies, and various settings. The packs can also be used to slim down images, so that they later load the host system as little as possible. Cloudpacks also include runtimes like JVM or Ruby when an application needs it.
It is interesting that the cloudpacks divide the images into layers. This allows you to update individual layers, such as the base image or runtime, while other layers remain unchanged. This makes updating an image much easier. This plays an important role when deploying containers in on-premises data centers and also in the cloud.
When used, buildpacks use the Detect script to detect which packs are required to build an application. If it is possible to continue using an existing layer from an existing build, the pack will retrieve that layer from the cache. Of course, this speeds up the creation of the image.
The easiest way to get started with Cloud Native buildpacks is to use the command line (CLI). Another way to use Cloud Native buildpacks is kpack from Pivotal. This is a Kubernetes native container build service. When used, kpack containerizes the application with Cloud Native buildpacks directly on the Kubernetes cluster.
Create, configure, and deploy Carvel Suite applications for Kubernetes
The Carvel Suite includes several tools to deploy applications to Kubernetes clusters. The most famous tools include ytt, kbld, kapp, imgpkg, kapp-controller and vendir.
yttTemplates are, for example, YAML documents consisting of maps and arrays. With ytt values can be set and instructions can be linked to maps and arrays. This is useful, for example, for loops.
kbld helps create images from applications. Like ytt, this tool relies on YAML files. It is interesting in this context that kbld can also access cloud Native buildpacks in the background. KBLD automatically updates the configuration with the newly created digest references. kbld automatically detects image references in the configuration and can create a lock file for the image. As a result, it can be determined at any time that the same image versions with their digests) are used. Other tools from the Carvel Suite can use these lock files for synchronization, for example. This ensures that the same versions are available on all data sources.
The tool kapp, in turn, allows the definition of various resources from Kubernetes as an application. This makes it possible to group resources. There are no server services required for the tool in the Kubernetes cluster and no elevated rights. The tool can also be used with limited rights. Through configuration files, kapp can customize the resources in the cluster to ensure that they match the state provided by the developers.
The kapp-controller provides deployment and package management for Kubernetes. This allows developers to create and manage their own applications. In addition, you can package your own applications and deploy them directly on the Kubernetes cluster. The configurations can pull kapp controllers from different sources, for example OCI registries or Git. Carvel’s various tools work together. Therefore, kapp-controller can also use templates from ytt and kbld. But other tools like helm also support kapp controllers.
With imgpkg bundles are created from Kubernetes and dependent OCI images. This allows a relocation of the cluster and its applications. At the new location, the content is then available in unchanged form. To do this, imgpkg creates OCI images that can be uploaded to any compatible container registries, such as DockerHub, Harbor, or ECR. When deploying again, imgpkp ensures that the download images match the upload images.
Vendir is a tool that can be used to synchronize different data sources into a common structure. This Carvel tool also relies primarily on YAML. Here Vendir can also access kbld’s lock files. Developers only need to control the desired directory structure with YAML and Vendir automatically takes over the synchronization tasks.
(ID: 47579843)
