Kubernetes Archives - credativ®

Introduction

For the first time ever, one of our colleagues had the chance to visit the North American edition of KubeCon and CloudNativeCon in Chicago this year.

Our colleague Michael Sprengel who already works 8 years for credativ and has gained a lot of experiences with Kubernetes and the development of Kubernetes controllers in that time, is sharing his experiences from KubeCon and CloudNativeCon North America 2023.

So with no further ado, let’s hand it over to our colleague Michael.

Come fly with me back to Chicago

Hi folks, my name is Michael Sprengel – Professional Service Consultant here at credativ – and I want to share my experiences with you from this year’s KubeCon / CloudNativeCon in North America. So come with me and let me give you a first person view of all the talks and things that I was able to experience here in Chicago. You may not had the chance to visit the North American edition of KubeCon so far, so this is the best chance for you to get some insights which could make you think of also attending KubeCon and CloudNativeCon next year then.

Those editions will take place in Paris and Salt Lake City.

Chicago – The Windy City

The good thing about such conferences is not only the possibility to attend talks and learn about new technologies that you can use in daily projects but it’s also an opportunity to learn new cultures and leave with a bag full of new memories.

This year, the conference took place in Chicago that is also known as the Windy City. I was lucky enough to arrive on Saturday, so that I had a chance to pack my backpack and pay Chicago a visit a day before the conference started. Hereby, I was able to check some of Chicago’s well known sights like for example Lake Michigan or the mighty Millennium Park in the center of Downtown Chicago.

The only downfall to this was that Chicago’s Cloud Gate that is also known as The Bean. This landmark is currently under construction at, so that I could only take a picture through some construction fences. But other than that, the city has a lot to offer like Deep Dish and Thin Crust Pizza or some university you may want to visit. Chicago is definitely worth it.

Day 1: Operator Day

Besides of this wonderful city, the actual conference has also a lot to offer. If you’re lucky enough to get a All-access pass for KubeCon, you can already visit some CNCF-hosted Co-located events near the venue. But don’t worry. Even if you don’t have such a pass, you can attend some virtual events already.

For me personally, I attended the so called Operator Day by Canonical. It’s a full day event that takes place from 9am to 4pm. It gave me some pretty good insights in implementing Kubernetes operators the Canonical way by using Juju.

Unfortunately, the current edition from Chicago isn’t online so far, but you can check out the last Operator Day from Europe by watching the videos below:

Day 2: First experiences from the venue

The second day was really mind blowing. If you never attended such a conference before, you will be surprised by the amount of talks as well as by the size of the actual venue.

After arriving at the venue, I had a chance to grab a breakfast and a coffee as well as attend the Opening Remarks in which leading Kubernetes and CNCF developers, engineers and ambassadors highlight the latest and greatest changes in Kubernetes and the CNCF space. Here, you could really feel how Machine Learning and AI is influencing Kubernetes and how features are added to this project to better support ML/AI.

Next to this, you have a big variety of talks that you can attend or you can go to the Solutions Showcase where all the major companies and sponsors have their booth. There, you can talk to maintainers or get in touch with companies that are using CNCF related projects or Kubernetes in their business. Typically some booths also offer so called Lightning Talks. These are like general talks but they tend to be shorter than the usual ones and they are mostly focusing on hands on sessions or live demos.

Day 3/4: Talks, talks and some more talks

In general, I was able to attend a lot of talks during the conference. Some of them were exactly what I was expecting and others however surprised me. Thereby, I visited the following talks:

Day 1

Day 2

Day 3

The Service Mesh Battle Scars talk was one of the talks that surprised me, because it was basically and public battle between the maintainers of the biggest Service Mesh solutions in Kubernetes.

  1. Cilium
  2. Istio
  3. linkerd

It surprised me because it was quite interesting to see how each of those projects were arguing differently to specific topics like transport encryption as well as Sidecar, Sideless or Ambient mode. As an attendee, you could really get a feeling of what thoughts each project put into specific topics before realizing them. Especially the topic about encryption caught my attention. Istio and linkerd simply use mTLS for encryption, whereas Cilium now tries to use TLS for the initial handshake while using the resulting encryption key for IPSec to implement transport encryption. This concept led to a heavy discussion if this approach is still considered to be secure since Cilium is only reusing some part of TLS instead of using it completely and usually reusing well known and accepted security algorithms is always preferred in modern IT.

Next to this, it was also pleasing to attend the Spotify talk in which Tim Hansen explained how the engineers at Spotify implement GitOps and what effort it takes to create a new project / repository that should be deployed on production. Spotify uses some self-written solutions to achieve this and overcome some limitation that already existing solutions might have. For building and deploying for example, Spotify uses their own CI/CD solution Tingle. Tingle was created in 2017 to serve as the centralized CI/CD system for backend, data and web services and it thereby replaced 200 stand-alone Jenkins machines. More information about this, can be found here:

How We Improved Developer Productivity for Our DevOps Teams

Although this talk mainly focused on Spotify and their GitOps tools, the presenter also showcased open source tools which helps to accomplish similar functionality without relying on Spotify’s own tools.

Overall, the majority of talks really helped me to broaden my knowledge regarding Kubernetes and the solutions out there. Only some talks didn’t match my expectation, but even then you still have plenty of other talks to choose from.

Get the first person view

If you want to get an idea of how such a conference looks like, I create three videos which let you experience the conference similar to what I was able to experience. Give it a try and visit KubeCon and CloudNativeCon 2023 with me again!

Conclusion

Having the opportunity to travel to Chicago and experience KubeCon and CloudNativeCon for the first time was an one in the lifetime experiences. You not only have the chance to get insights to so many CNCF related projects but it’s also a good opportunity to get in touch with developers, engineers, managers and other people who use Kubernetes on daily basis. If you have the chance to visit such a conference, I would highly recommend to take the chance and attend them.

On KubeCon and CloudNativeCon, I learned a lot about new stuff and got an idea of design decision that probably will help me to solve some upcoming challenges in one of my own projects and which I wouldn’t know about if I hadn’t attended this conference. Thereby, one quote from Dr. Angel Diaz, VP Technology Capabilities & Innovation at Discover Financial Services really stick to my head:

Code, Community, Culture

And this is what it’s all about. You not only learn new stuff that you can use in your code, but you become a part of a community and get use to a culture which enables you to contribute to projects that are the baseline of most of our daily projects.

With a lot of Deep Dish Pizza in my stomach and a lot of new knowledge in my head, I’m happy to return from KubeCon North America and start working on my Kubernetes projects again.

Thanks for sticking around with me and I hope to see you on next year’s KubeCon and CloudNativeCon, too.

And by the way, if you’re searching for experts in Kubernetes and CNCF related topics, give our sales department a call and we might be able to help you with that.

In this article we will look at the highly available operation of PostgreSQL® in a Kubernetes environment. A topic that is certainly of particular interest to many of our PostgreSQL® users.

Together with our partner company MayaData, we will demonstrate below the application possibilities and advantages of the extremely powerful open source project – OpenEBS.

OpenEBS is a freely available storage management system, whose development is supported and backed by MayaData.

We would like to thank Murat-Karslioglu from MayaData and our colleague Adrian Vondendriesch for this interesting and helpful article. This article simultaneously also appeared on OpenEBS.io.

PostgreSQL® anywhere — via Kubernetes with some help from OpenEBS and credativ engineering

by Murat Karslioglu, OpenEBS and Adrian Vondendriesch, credativ

Introduction

If you are already running Kubernetes on some form of cloud whether on-premises or as a service, you understand the ease-of-use, scalability and monitoring benefits of Kubernetes — and you may well be looking at how to apply those benefits to the operation of your databases.

PostgreSQL® remains a preferred relational database, and although setting up a highly available Postgres cluster from scratch might be challenging at first, we are seeing patterns emerging that allow PostgreSQL® to run as a first class citizen within Kubernetes, improving availability, reducing management time and overhead, and limiting cloud or data center lock-in.

There are many ways to run high availability with PostgreSQL®; for a list, see the PostgreSQL® Documentation. Some common cloud-native Postgres cluster deployment projects include Crunchy Data’s, Sorint.lab’s Stolon and Zalando’s Patroni/Spilo. Thus far we are seeing Zalando’s operator as a preferred solution in part because it seems to be simpler to understand and we’ve seen it operate well.

Some quick background on your authors:

  • OpenEBS is a broadly deployed OpenSource storage and storage management project sponsored by MayaData.
  • credativ is a leading open source support and engineering company with particular depth in PostgreSQL®.

In this blog, we’d like to briefly cover how using cloud-native or “container attached” storage can help in the deployment and ongoing operations of PostgreSQL® on Kubernetes. This is the first of a series of blogs we are considering — this one focuses more on why users are adopting this pattern and future ones will dive more into the specifics of how they are doing so.

At the end you can see how to use a Storage Class and a preferred operator to deploy PostgreSQL® with OpenEBS underlying

If you are curious about what container attached storage of CAS is you can read more from the Cloud Native Computing Foundation (CNCF) here.

Conceptually you can think of CAS as being the decomposition of previously monolithic storage software into containerized microservices that themselves run on Kubernetes. This gives all the advantages of running Kubernetes that already led you to run Kubernetes — now applied to the storage and data management layer as well. Of special note is that like Kubernetes, OpenEBS runs anywhere so the same advantages below apply whether on on-premises or on any of the many hosted Kubernetes services.

PostgreSQL® plus OpenEBS

®-with-OpenEBS-persistent-volumes.png”>Postgres-Operator (for cluster deployment)

  • Docker installed
  • Kubernetes 1.9+ cluster installed
  • kubectl installed
  • OpenEBS installed
  • Install OpenEBS

    1. If OpenEBS is not installed in your K8s cluster, this can be done from here. If OpenEBS is already installed, go to the next step.
    2. Connect to MayaOnline (Optional): Connecting the Kubernetes cluster to MayaOnline provides good visibility of storage resources. MayaOnline has various support options for enterprise customers.

    Configure cStor Pool

    1. If cStor Pool is not configured in your OpenEBS cluster, this can be done from here. As PostgreSQL® is a StatefulSet application, it requires a single storage replication factor. If you prefer additional redundancy you can always increase the replica count to 3.
      During cStor Pool creation, make sure that the maxPools parameter is set to >=3. If a cStor pool is already configured, go to the next step. Sample YAML named openebs-config.yaml for configuring cStor Pool is provided in the Configuration details below.

    openebs-config.yaml

    #Use the following YAMLs to create a cStor Storage Pool.
    # and associated storage class.
    apiVersion: openebs.io/v1alpha1
    kind: StoragePoolClaim
    metadata:
     name: cstor-disk
    spec:
     name: cstor-disk
     type: disk
     poolSpec:
     poolType: striped
     # NOTE — Appropriate disks need to be fetched using `kubectl get disks`
     #
     # `Disk` is a custom resource supported by OpenEBS with `node-disk-manager`
     # as the disk operator
    # Replace the following with actual disk CRs from your cluster `kubectl get disks`
    # Uncomment the below lines after updating the actual disk names.
     disks:
     diskList:
    # Replace the following with actual disk CRs from your cluster from `kubectl get disks`
    # — disk-184d99015253054c48c4aa3f17d137b1
    # — disk-2f6bced7ba9b2be230ca5138fd0b07f1
    # — disk-806d3e77dd2e38f188fdaf9c46020bdc
    # — disk-8b6fb58d0c4e0ff3ed74a5183556424d
    # — disk-bad1863742ce905e67978d082a721d61
    # — disk-d172a48ad8b0fb536b9984609b7ee653
     — -

    Create Storage Class

    1. You must configure a StorageClass to provision cStor volume on a cStor pool. In this solution, we are using a StorageClass to consume the cStor Pool which is created using external disks attached on the Nodes. The storage pool is created using the steps provided in the Configure StoragePool section. In this solution, PostgreSQL® is a deployment. Since it requires replication at the storage level the cStor volume replicaCount is 3. Sample YAML named openebs-sc-pg.yaml to consume cStor pool with cStorVolume Replica count as 3 is provided in the configuration details below.

    openebs-sc-pg.yaml

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: openebs-postgres
      annotations:
        openebs.io/cas-type: cstor
        cas.openebs.io/config: |
          - name: StoragePoolClaim
            value: "cstor-disk"
          - name: ReplicaCount
            value: "3"       
    provisioner: openebs.io/provisioner-iscsi
    reclaimPolicy: Delete
    ---

    Launch and test Postgres Operator

    1. Clone Zalando’s Postgres Operator.
    git clone https://github.com/zalando/postgres-operator.git
    cd postgres-operator

    Use the OpenEBS storage class

    1. Edit manifest file and add openebs-postgres as the storage class.
    nano manifests/minimal-postgres-manifest.yaml

    After adding the storage class, it should look like the example below:

    apiVersion: "acid.zalan.do/v1"
    kind: postgresql
    metadata:
      name: acid-minimal-cluster
      namespace: default
    spec:
      teamId: "ACID"
      volume:
        size: 1Gi
        storageClass: openebs-postgres
      numberOfInstances: 2
      users:
        # database owner
        zalando:
        - superuser
        - createdb
     
    # role for application foo
        foo_user: []
     
    #databases: name->owner
      databases:
        foo: zalando
      postgresql:
        version: "10"
        parameters:
          shared_buffers: "32MB"
          max_connections: "10"
          log_statement: "all"

    Start the Operator

    1. Run the command below to start the operator
    kubectl create -f manifests/configmap.yaml # configuration
    kubectl create -f manifests/operator-service-account-rbac.yaml # identity and permissions
    kubectl create -f manifests/postgres-operator.yaml # deployment

    Create a Postgres cluster on OpenEBS

    Optional: The operator can run in a namespace other than default. For example, to use the test namespace, run the following before deploying the operator’s manifests:

    kubectl create namespace test
    kubectl config set-context $(kubectl config current-context) — namespace=test
    1. Run the command below to deploy from the example manifest:
    kubectl create -f manifests/minimal-postgres-manifest.yaml

    2. It only takes a few seconds to get the persistent volume (PV) for the pgdata-acid-minimal-cluster-0 up. Check PVs created by the operator using the kubectl get pv command:

    $ kubectl get pv
    NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
    pvc-8852ceef-48fe-11e9–9897–06b524f7f6ea 1Gi RWO Delete Bound default/pgdata-acid-minimal-cluster-0 openebs-postgres 8m44s
    pvc-bfdf7ebe-48fe-11e9–9897–06b524f7f6ea 1Gi RWO Delete Bound default/pgdata-acid-minimal-cluster-1 openebs-postgres 7m14s

    Connect to the Postgres master and test

    1. If it is not installed previously, install psql client:
    sudo apt-get install postgresql-client

    2. Run the command below and note the hostname and host port.

    kubectl get service — namespace default |grep acid-minimal-cluster

    3. Run the commands below to connect to your PostgreSQL® DB and test. Replace the [HostPort] below with the port number from the output of the above command:

    export PGHOST=$(kubectl get svc -n default -l application=spilo,spilo-role=master -o jsonpath="{.items[0].spec.clusterIP}")
    export PGPORT=[HostPort]
    export PGPASSWORD=$(kubectl get secret -n default postgres.acid-minimal-cluster.credentials -o ‘jsonpath={.data.password}’ | base64 -d)
    psql -U postgres -c ‘create table foo (id int)’

    Congrats you now have the Postgres-Operator and your first test database up and running with the help of cloud-native OpenEBS storage.

    Partnership and future direction

    As this blog indicates, the teams at MayaData / OpenEBS and credativ are increasingly working together to help organizations running PostgreSQL® and other stateful workloads. In future blogs, we’ll provide more hands-on tips.

    We are looking for feedback and suggestions on where to take this collaboration. Please provide feedback below or find us on Twitter or on the OpenEBS slack community.