Search the Community

Quiz #17 was: You’re working in a GitOps environment where developers use Helm charts to manage Kubernetes deployments. One day, a developer makes a change to a Helm chart to adjust the replica count of a deployment. However, after the change is applied, you notice that the deployment’s pod template has also been unexpectedly modified, […]View the full article

Google Cloud's Apigee API Management allows the freedom to deploy your APIs anywhere — in your own data center or public cloud of your choice — by configuring Apigee Hybrid. You can host and manage containerized runtime services in your own Kubernetes cluster for greater agility and interoperability while managing APIs consistently with Apigee. Until now, customers have used apigeectl, a purpose-built tool, to install Apigee Hybrid. But customers tell us they want to leverage their existing tooling to automate their installation following the gitops model. So today, we’re thrilled to announce a new way to installApigee Hybrid (as of 1.11 release) using the Helm package manager. Using Helm opens an ecosystem of tools that you can use to automate both the installation and Day 2 operations of Apigee Hybrid. What are Helm charts, and why did we choose them?Helm charts are a way to package, version, and deploy software on Kubernetes. They are a popular choice for deploying applications because they offer a number of advantages over other methods, such as: Ease of use: Helm charts are easy to use, even for users who may not be as familiar with Kubernetes.Reproducibility: Helm charts make it easy to reproduce deployments.Versioning: Helm charts allow you to track the versions of the software you are deploying.Automation: Helm charts can be used to automate the deployment of software.In addition, Helm charts are supported by a large community of users and developers, which means that there is a wealth of resources available to help you get started. One of the key considerations for selecting Helm charts is that it is sticky (stateful) in nature. It creates an object if, and only if, the object does not existIt updates an object if, and only if, it was installed using the Helm chart with the same name.Helm helps to easily navigate multiple components of Apigee Hybrid. The core components of Apigee Hybrid are divided into distinct charts to make them easier to manage and update. This separation minimizes risk and enhances adaptability as your Apigee environment expands, helping to simplify Day 2 operations. Below are the Helm charts for Apigee Hybrid’s components. apigee-operatorapigee-datastoreapigee-telemetryapigee-redisapigee-Ingress-managerapigee-orgapigee environmentsapigee-virtualhostapigee-datastore-data-replicationBenefits of using Helm charts with Apigee HybridThere are a number of benefits to using Helm charts with Apigee Hybrid, including: Simplified deployment and management of Apigee Hybrid custom resource objects and componentsNative Kubernetes integration and a robust ecosystem of supporting toolsConsistency and repeatabilityUniform and repeatable deployments across multiple Kubernetes clustersIdeal for managing various software development lifecycle clusters and regional production expansionsHow to use Helm charts with Apigee HybridTo use Helm charts with Apigee Hybrid, you will need to have cert-manager and the Apigee Hybrid CRDs ( custom resource definitions) installed on your Kubernetes cluster. You will also need to install Helm on the client used to deploy into your Kubernetes cluster. cluster. Purpose and use of CRDs (custom resource definitions) The Apigee Hybrid runtime consists of multiple components that have to work together to provide the features and functionality you expect from a best-in-class API management solution. The use of CRDs allows us to ensure that the components are set up correctly and mask any domain-specific logic needed, ensuring a robust and reliable runtime. Why no Helm charts for the CRDs? New releases of Apigee Hybrid may necessitate updating the CRDs. Currently, Helm charts do not support creating and updating CRDs. This is not only related to Helm support for CRDs, it also allows for simpler privilege management as this step requires escalated cluster privileges (i.e., cluster-admin cluster role privileges) to install the CRDs. Please visit this guide for more detailed steps on how to install and manage Apigee Hybrid with Helm charts. The diagram below shows the installation sequence when installing Apigee Hybrid with Helm charts. Best practices for using Helm charts with Apigee HybridHere are several best practices we have found make it easier to use Helm charts with Apigee Hybrid. Organize your code in a monorepo. This will make it easier to manage your code and deploy changes to your Apigee Hybrid environment.Upgrade all components to the same chart version. Don't upgrade components at different times.Use the official Apigee Hybrid Helm charts from Google Cloud. This set of charts is maintained and updated regularly.Use Helm templates to customize your deployment. This will allow you to manage the lifecycle of your Apigee Hybrid deployments without having to modify the Helm chart itself.Automate your deployments. This will make your deployments consistent, repeatable, and upgradable.Monitor your Apigee Hybrid Chart deployments to ensure that all components are created successfully. Deploying a chart doesn’t necessarily guarantee that all the components and the underlying Kubernetes resources are installed and healthy. Monitor and build tests for automation to ensure that all of the components appear as expected.Automation with Helm chartsNow, let’s go over some tools that can automate deploying Apigee Hybrid with Helm charts. Helm charts introduce automation when creating numerous Apigee Hybrid components. This helps to streamline the deployment process and reduce human error. You can store your Helm charts in a repository of choice, such as Github, bitbucket, and more. To pull charts and create their respective resources, you can use a GitOps style tool, such as ArgoCD, ansible, or flux. You can also have custom values to override the default values or configuration to be applied to the components for each chart as they get created. This will allow you to have a pipeline to create and also manage the lifecycle of various Apigee hybrid components. It also enables you to upgrade the components independently. This setup can be implemented as part of a customer’s full software development lifecycle across multiple environments, such as development, staging, and production. In this scenario, the pipeline creates the underlying infrastructure and the values are custom and specified to each environment. For more details about setting up Apigee Hybrid using ArgoCD and Helm, please see the community article, “Apigee Hybrid Deployment using ArgoCD and Helm.” For more details about setting up Apigee Hybrid deployment using Ansible and Helm please see this community article, “Accelerate your Apigee Hybrid management with Ansible & Helm.” Apigee Hybrid versions supported by Helm chartsHelm charts were introduced in Apigee Hybrid 1.10, so first make sure your version of Apigee Hybrid offers support. Second, you will need to follow these instructions to convert your Apigeectl-based install to a Helm-based install.

Do you find yourself lying awake late at night, worried that your greatest observability fears will materialize as one of the most horrific specters of Kubernetes-driven chaos reaches up through your mattress to consume your very soul? Even as your mind races and you wonder just who that creepy character sneaking around the metaphysical boiler […]View the full article

With Argo CD or OpenShift GitOps, deploying Helm Charts and leveraging the power of templating is simple. However, while working with different cluster environments, the question sometimes arises: How can I make sure that a new version of a Chart is first deployed on the DEV-environment only before it is installed on the PROD-environment? ... View the full article

AWS unveils new capabilities for cdk8s, allowing seamless synthesis of applications into Helm charts on one hand, and native import of existing Helm charts into cdk8s applications on the other. In addition, cdk8s can now interpret deploy-time tokens of the AWS CDK and CDK For Terraform, all during the cdk8s synthesis phase. Helm stands out as a widely embraced solution for the deployment and management of Kubernetes applications. By converging cdk8s and Helm, users can enjoy a unified workflow for creating and deploying Kubernetes manifests. With the recent addition to the "cdk8s synth" command, you can transform a cdk8s app directly into a Helm Chart, ready to be integrated with Helm deployments. View the full article

At some point during the OpenShift deployment phase, a question about project onboarding comes up, "How can a new customer or tenant be onboarded so they can deploy their own workload onto the cluster(s)?" While there are different ways from a process perspective (Service Now, Jira, etc.), I focus on the Kubernetes objects that must be created on each cluster. In A Guide to GitOps and Argo CD with RBAC, I described setting up GitOps RBAC rules so tenants can work with their (and only their) projects. This article demonstrates another possibility for deploying per tenant and per cluster ... View the full article

One principle of GitOps is to have the desired state declarations as Versioned and Immutable, where Git repositories play an important role as the source of truth. But can you have an alternative to a Git repository for storing and deploying your Kubernetes manifests via GitOps? What if you could package your Kubernetes manifests into a container image instead? What if you can reuse the same authentication and authorization mechanism as your container images? To answer the above questions, an understanding of OCI registries and OCI artifacts is needed. Simply put, OCI registries are the registries that are typically used for container images but can be expanded to store other types of data (aka OCI artifacts) such as Helm charts, Kubernetes manifests, Kustomize overlays, scripts, etc. Using OCI Registries and OCI Artifacts provides you with the following advantages: Less tools to operate: Single artifact registry can store expanded data types apart from container images. In-built release archival system: OCI registries give users two sets of mutable and immutable URLs which are tags and content-addressable ones. Flourishing ecosystem: Standardized and supported by dozen of providers which helps users take advantage of new features and tools developed by large Kubernetes community Given these benefits, and in addition to the support of files stored in Git repositories, we are thrilled to announce two new formats supported by Config Sync 1.13 to deploy OCI artifacts: Sync OCI artifacts from Artifact Registry Sync Helm charts from OCI registries Config Sync is an open source tool that provides GitOps continuous delivery for Kubernetes clusters. The Open Container Initiative (OCI) is an open governance structure for the express purpose of creating open industry standards around container formats and runtimes. OCI artifacts give you the power of storing and distributing different types of data such as Kubernetes manifests, Helm Charts, and Kustomize overlays, in addition to container images via OCI registries. Throughout this blog, you will see how you can leverage the two new formats (OCI artifacts and Helm charts) supported by Config Sync, by using: oras and helm to package and push OCI artifacts Artifact registry as OCI registry to store the OCI artifacts GKE cluster to host the OCI artifacts synced Config Sync installed in that GKE cluster to sync the OCI artifacts Initial setup First, you need to have a common setup for the two scenarios by configuring and securing the access from the GKE cluster with Config Sync to the Artifact Registry repository. Initialize the Google Cloud project you will use throughout this blog: code_block [StructValue([(u'code', u'PROJECT=SET_YOUR_PROJECT_ID_HERE\r\ngcloud config set project $PROJECT'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca253a6c10>)])] Create a GKE cluster with Workload Identity registered in a fleet to enable Config Management: code_block [StructValue([(u'code', u'CLUSTER_NAME=oci-artifacts-cluster\r\nREGION=us-east4\r\ngcloud services enable container.googleapis.com\r\ngcloud container clusters create ${CLUSTER_NAME} \\\r\n --workload-pool=${PROJECT}.svc.id.goog \\\r\n --region ${REGION}\r\ngcloud services enable gkehub.googleapis.com\r\ngcloud container fleet memberships register ${CLUSTER_NAME} \\\r\n --gke-cluster ${REGION}/${CLUSTER_NAME} \\\r\n --enable-workload-identity\r\ngcloud beta container fleet config-management enable'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca263d4e10>)])] Install Config Sync in the GKE cluster: code_block [StructValue([(u'code', u'cat <<EOF > acm-config.yaml\r\napplySpecVersion: 1\r\nspec:\r\n configSync:\r\n enabled: true\r\nEOF\r\ngcloud beta container fleet config-management apply \\\r\n --membership ${CLUSTER_NAME} \\\r\n --config acm-config.yaml'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca263d4cd0>)])] Create an Artifact Registry repository to host OCI artifacts (--repository-format docker): code_block [StructValue([(u'code', u'CONTAINER_REGISTRY_NAME=oci-artifacts\r\ngcloud services enable artifactregistry.googleapis.com\r\ngcloud artifacts repositories create ${CONTAINER_REGISTRY_NAME} \\\r\n --location ${REGION} \\\r\n --repository-format docker'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca15b519d0>)])] Create a dedicated Google Cloud Service Account with the fine granular access to that Artifact Registry repository with the roles/artifactregistry.reader role: code_block [StructValue([(u'code', u'GSA_NAME=oci-artifacts-reader\r\ngcloud iam service-accounts create ${GSA_NAME} \\\r\n --display-name ${GSA_NAME}\r\ngcloud artifacts repositories add-iam-policy-binding ${CONTAINER_REGISTRY_NAME} \\\r\n --location ${REGION} \\\r\n --member "serviceAccount:${GSA_NAME}@${PROJECT}.iam.gserviceaccount.com" \\\r\n --role roles/artifactregistry.reader'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca15b51090>)])] Allow Config Sync to synchronize resources for a specific RootSync: code_block [StructValue([(u'code', u'ROOT_SYNC_NAME=root-sync-oci\r\ngcloud iam service-accounts add-iam-policy-binding \\\r\n --role roles/iam.workloadIdentityUser \\\r\n --member "serviceAccount:${PROJECT}.svc.id.goog[config-management-system/root-reconciler-${ROOT_SYNC_NAME}]" \\\r\n ${GSA_NAME}@${PROJECT}.iam.gserviceaccount.com'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca26ce6cd0>)])] Login to Artifact Registry so you can push OCI artifacts to it in a later step: code_block [StructValue([(u'code', u'gcloud auth configure-docker ${REGION}-docker.pkg.dev'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca26ce61d0>)])] Build and sync an OCI artifact Now that you have completed your setup, let's illustrate our first scenario where you want to sync a Namespace resource as an OCI image. Create a Namespace resource definition: code_block [StructValue([(u'code', u'cat <<EOF> test-namespace.yaml\r\napiVersion: v1\r\nkind: Namespace\r\nmetadata:\r\n name: test\r\nEOF'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca26ce6350>)])] Create an archive of that file: code_block [StructValue([(u'code', u'tar -cf test-namespace.tar test-namespace.yaml'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca26ce6990>)])] Push that artifact to Artifact Registry. In this tutorial, we use oras, but there are other tools that you can use like crane. code_block [StructValue([(u'code', u'oras push \\\r\n ${REGION}-docker.pkg.dev/${PROJECT}/${CONTAINER_REGISTRY_NAME}/my-namespace-artifact:v1 \\\r\n test-namespace.tar'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca26ce6290>)])] Set up Config Sync to deploy this artifact from Artifact Registry: code_block [StructValue([(u'code', u'cat << EOF | kubectl apply -f -\r\napiVersion: configsync.gke.io/v1beta1\r\nkind: RootSync\r\nmetadata:\r\n name: ${ROOT_SYNC_NAME}\r\n namespace: config-management-system\r\nspec:\r\n sourceFormat: unstructured\r\n sourceType: oci\r\n oci:\r\n image: ${REGION}-docker.pkg.dev/${PROJECT}/${CONTAINER_REGISTRY_NAME}/my-namespace-artifact:v1\r\n dir: .\r\n auth: gcpserviceaccount\r\n gcpServiceAccountEmail: ${GSA_NAME}@${PROJECT}.iam.gserviceaccount.com\r\nEOF'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca14f1eb10>)])] Check the status of the sync with the nomos tool: code_block [StructValue([(u'code', u'nomos status --contexts $(k config current-context)'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca14f1ef50>)])] Verify that the Namespace test is synced: code_block [StructValue([(u'code', u'kubectl get ns test'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca14f1e990>)])] And voilà! You just synced a Namespace resource as an OCI artifact with Config Sync. Build and sync a Helm chart Now, let's see how you could deploy a Helm chart hosted in a private Artifact Registry. Create a simple Helm chart: code_block [StructValue([(u'code', u'helm create test-chart'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca25ff7f50>)])] Package the Helm chart: code_block [StructValue([(u'code', u'helm package test-chart --version 0.1.0'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca2434b150>)])] Push the chart to Artifact Registry: code_block [StructValue([(u'code', u'helm push \\\r\n test-chart-0.1.0.tgz \\\r\n oci://${REGION}-docker.pkg.dev/${PROJECT}/${CONTAINER_REGISTRY_NAME}'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca1580b890>)])] Set up Config Sync to deploy this Helm chart from Artifact Registry: code_block [StructValue([(u'code', u'cat << EOF | kubectl apply -f -\r\napiVersion: configsync.gke.io/v1beta1\r\nkind: RootSync\r\nmetadata:\r\n name: ${ROOT_SYNC_NAME}\r\n namespace: config-management-system\r\nspec:\r\n sourceFormat: unstructured\r\n sourceType: helm\r\n helm:\r\n repo: oci://${REGION}-docker.pkg.dev/${PROJECT}/${CONTAINER_REGISTRY_NAME}\r\n chart: test-chart\r\n version: 0.1.0\r\n releaseName: test-chart\r\n namespace: default\r\n auth: gcpserviceaccount\r\n gcpServiceAccountEmail: ${GSA_NAME}@${PROJECT}.iam.gserviceaccount.com\r\nEOF'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca1580b290>)])] Check the status of the sync with the nomos tool: code_block [StructValue([(u'code', u'nomos status --contexts $(k config current-context)'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca1580bc10>)])] Verify that the resources in the Namespace test-chart are synced: code_block [StructValue([(u'code', u'kubectl get all -n default'), (u'language', u''), (u'caption', <wagtail.wagtailcore.rich_text.RichText object at 0x3eca25bd62d0>)])] And voilà! You just synced an Helm chart with Config Sync. Towards more scalability and security In this blog, you synced both an OCI artifact and an Helm chart with Config Sync. OCI registries and OCI artifacts are new kids on the block that can also work alongside with the Git option depending on your needs and use-cases. One of such patterns could be Git still acting as the source of truth for the declarative configs in addition to the well established developer workflow it provides: pull request, code review, branch strategy, etc. The continuous integration pipelines, triggered by pull requests or merges, will run tests against the declarative configs to eventually push the OCI artifacts in an OCI registry. Finally, the continuous reconciliation of GitOps will take it from here and will reconcile between the desired state, now stored in an OCI registry, with the actual state, running in Kubernetes. Your Kubernetes manifests as OCI artifacts are now just seen like any container images for your Kubernetes clusters as they are pulled from OCI registries. This continuous reconciliation from OCI registries, not interacting with Git, has a lot of benefits in terms of scalability, performance and security as you will be able to configure very fine grained access to your OCI artifacts. To get started, check out the two Sync OCI artifacts from Artifact Registry and the Sync Helm charts from OCI registries features today. You could also find this other tutorial showing how you can package and push an Helm chart to GitHub Container Registry with GitHub actions, and then how you can deploy this Helm chart with Config Sync. Attending KubeCon + CloudNativeCon North America 2022 in October? Come check out our session Build and Deploy Cloud Native (OCI) Artifacts, the GitOps Way during the GitOpsCon North America 2022 co-located event on October, 25th. Hope to see you there! Config Sync is open sourced. We are open to contributions and bug fixes if you want to get involved in the development of Config Sync. You can also use the repository to track ongoing work, or build from source to try out bleeding-edge functionalities. Related Article Google Cloud at KubeCon EU: New projects, updated services, and how to connect Engage with experts and learn more about Google Kubernetes Engine at KubeCon EU. Read Article

Helm is a Kubernetes package manager for deploying helm charts (collections of pre-configured Kubernetes application resources). It features all the necessary commands for the simpler management of apps in a Kubernetes cluster. This article covers all important Helm operations and provides examples to help you understand its syntax and features. https://faun.pub/helm-command-cheat-sheet-by-m-sharma-488706ecf131

Overview of Helm ...

What is Helm? What are Helm tasks and components? What are Helm charts? How to install Helm? Everything you need to know about Helm - Part I Everything you need to know about Helm - Part II

The Linux Foundation has launched an advanced cloud engineer Bootcamp to take your career to the next level by enabling IT administrators to learn the most sought after cloud skills and get certified in six months. This Bootcamp covers the whole Kubernetes ecosystem from essential topics like containers, Kubernetes deployments, logging, Prometheus monitoring to advanced topics like service mesh. Basically all the skills required to work in a Kubernetes based project. And here is the best part. With this Bootcamp, you can take the Kubernetes CKA certification exam. It comes with one-year validity and a free retake. Here is the list of courses covered in the Bootcamp. Containers Fundamentals (LFS253) Kubernetes Fundamentals (LFS258) Service Mesh Fundamentals (LFS243) Monitoring Systems and Services with Prometheus (LFS241) Cloud-Native Logging with Fluentd (LFS242) Managing Kubernetes Applications with Helm (LFS244) Certified Kubernetes Administrator Exam (CKA) Advanced Cloud Engineer Bootcamp is priced at $2300 (List Price) but if you join before 31st July, you can get it for $599 (saves you $1700). You may also use the DCUBEOFFER coupon code at check out to get an additional 15% discount on total cart value (Applicable for CKA & CKAD certifications as well). Access Advanced Cloud Engineer Bootcamp Note*: It comes with a 30 days money back guarantee How The Cloud Engineer Bootcamp Work? The whole Bootcamp is designed for six months. All the courses in the Bootcamp are self-paced. Ideally, you should spend 10 hours per week for six months to complete all the courses in the Bootcamp. Even though the courses are self-paced, you will get access to interactive forums and live chat within course instructors. Every course is associated with hands-on labs and assignments to improve your practical knowledge. At the end of the Bootcamp, you can appear for the CKA exam completely free with one-year validity a free retake You will earn a valid advanced cloudeningeer bootcamp badge and CKA certification badge. Is Cloud Engineer Bootcamp Worth It? If you are an IT administrator or someone who wants to learn the latest cloud-native technologies, this is one of the best options as it focuses more on the practical aspects. If you look at the price, it’s worth it as you will have to spend $2300 if you buy those courses individually. Even the much sought after CKA certification will cost you $300. With an additional $300, you get access to all the other courses plus support for dedicated forums and live instructor sessions. So it is entirely on you how you make use of this Bootcamp. Like learning any technology, you have to put in your work using these resources. View the full article