Stichword-Archiv: opensource

Kubernetes: Distributing Pods of a Deployment across nodes

Mai 17, 2022 9:14 am Veröffentlicht von

Sometimes you need to ensure that the pods of a deployment are not deployed to the same node. To achieve this, you can use the pod anti-affinity and configure it so that pods do not get deployed to pods of the same deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: game
  name: game
  namespace: arcade
spec:
  progressDeadlineSeconds: 600
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: game
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: game
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - game
            topologyKey: kubernetes.io/hostname
      containers:
      - image: quay.io/mdewald/s3e
        name: s3e

This pod anti-affinity definition will not deploy any 2 pods of the deployment onto the same node.

During the roll-out, additional pods are created before old pods are removed. If you have the same number of nodes as replicas, that means the roll-out won’t happen: No node is available to suffice the criteria to deploy an additional pod. So in the best case, you should have more nodes available than the deployment requires replicas.

You can work around this problem by changing from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringScheduilingIgnoredDuringExecution:

podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - game
        topologyKey: kubernetes.io/hostname
    weight: 100

However, this would allow some of the pods of the deployment to land on the same node during a roll-out of the deployment. After the roll-out, they will be distributed one pod per node again.

If you absolutely don’t want to ever have 2 pods of the same deployment run on the same node but don’t have more nodes than replicas, it can be an option for you to migrate from a Deployment to StatefulSet, which will first terminate each pod before creating a new one:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: game
  name: game
  namespace: arcade
spec:
  replicas: 2
  selector:
    matchLabels:
      app: game
  serviceName: ""
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: game
    spec:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - game
            topologyKey: kubernetes.io/hostname
      containers:
      - image: quay.io/mdewald/s3e
        name: s3e

This will ensure no pod of the StatefulSet is scheduled to the same node. If you have the same number of nodes as replicas in the StatefulSet the rollout will do the following: One by one, the pods will be removed and the replacement will be scheduled to the same node before the next pod is removed.

Raspberry Pi powered Wifi Pictureframe

März 6, 2019 7:09 am Veröffentlicht von
Some days ago I wrote an post about building a picture frame using a Raspberry Pi. The article has been published on opensource.com. The software to show the slideshow has been written by myself and published on github as I wasn’t happy with all the existing solutions. As they either involve using a GL rendered xscreensaver which was terribly slow on the Raspberry Pi or installing Kodi which I think is kind of overkill, just to get a slide show.
Also I wanted the nice feature of a blurred, screen-filling version of the image displayed in the background. This is not possible using the xscreensaver slide show.
Take a look at it if you are as well looking for a lightweight slide show software and let me know what you think!

    Blogpost: CloudFoundry Summit Europe 2018

    Dezember 18, 2018 7:31 am Veröffentlicht von

    After attending CloudFoundry Summit 2018 in Basel in October, I published an event summary together with my colleagues. This writing summarizes the talks that where interesting from the perspective of us as BOSH developers. You can find the post on the community page of SAP.

    Recap and collected replays: Cloud Foundry Summit Europe 2018 — thanks @ManuelDewald and team! #cfsummit @cloudfoundryhttps://t.co/t7b6NjplyN

    — SAP Cloud Platform (@sapcp) 6. November 2018

    Watch all talks online via the youtube playlist.

    RaspberryPi NAS

    Juli 27, 2018 7:47 am Veröffentlicht von

    Guest Series at opensource.com

    After my recent first guest article on https://opensource.com the first part of a series about creating a Raspberry Pi based NAS has just been published. You can read it hier kontaktieren. There has been a surprising amount of twitter reactions to the article and it seems it also collected more than a thousand visits on the first day.

    Building a network attached storage device with a #RaspberryPi https://t.co/PrNwRsZnjr via @opensourceway by @manueldewald #RPi #OpenSource #FOSS

    — Juha Remes (@jremes84) 24. Juli 2018

    Update: Part II has ben published yesterday, with a similar reaction as the first one. Seems the topic of creating a NAS using a Raspberry Pi for private usage is quite popular. Also, thanks to Jen for editing my articles to make the text more readable.

    Automating backups on a Raspberry Pi NAS https://t.co/mT87JYvVYT via @opensourceway by @manueldewald

    — Jen Wike Huger (@JenWike) 14. August 2018

    Update 19.09.18: the third and final path of the Raspberry Pi NAS has been published. Already in the first 24 hours a big number of tweets and retweets shows that there is some interest in this topic. This part explains how to install Nextcloud on a Raspberry Pi.

    Thanks to the opensource.com team for encouraging me to start writing guest posts! It’s a nice experience to work with you.

    Use Ansible to clone & update private git repositories via ssh

    Juli 7, 2018 7:21 am Veröffentlicht von

    One of the first things I wanted to do when I started using Ansible was to clone a git repository on a remote machine as I keep configuration, scripts, and source code in github or gitlab repositories. Things that are not meant for the public, I store in private repositories that I want to clone via ssh. Cloning and updating them I now want to automate with Ansible.

    There are different ways to go for this task:

    • Checkout the repo locally and copy it to the server via a Ansible synchronize task
    • Generate an ssh key on the server and allow cloning the repo with that key manually
    • Copy a local ssh key to the server and allow cloning the repo with that key
    • use ssh-agent to load the local key and forward the agent to the server
    While it might be tempting to just copy an ssh key via Ansible to the remote server, I find this quite risky,  as it means you copy a secret to a persistent storage on a remote server. Also, if you version your Ansible playbooks in a git repository as well to be able to execute the playbook from somewhere else, the private key has to be versioned along with it.

    Using ssh-agent, you can easily load your ssh key prior to provisioning the git repo on the remote server without copying it over, and without allowing access to your repo for a different key than the one you have granted access for development.
    Let’s go through this via a simple example. Let’s say you want to run the following playbook, which includes ensuring the git repository github.com/ntlx/my-private-repo is up-to-date.

    1
    2
    3
    4
    5
    6
    7
    ---
    - hosts: webserver
      tasks:
          - name: Ensure repo is up-to-date
            git:
                repo: git@github.com/ntlx/my-private-repo.git
                dest: repos/my-private-repo
    
    I assume you added your public ssh key to your github.com repository so you are able to clone and work on the repository locally. To clone the repository on the remote machine, you need to load your ssh-key to ssh-agent with the following command.

    ssh-add ~/.ssh/id_rsa
    

    Now we need to enable the forwarding of the ssh agent to the remote machine so we can access the loaded key remotely. There are different ways to do so, but I find it most useful to do it in your ansible.cfg like this:

    1
    2
    [ssh_connection]
    ssh_args=-o ForwardAgent=yes
    

    That way, you allow the forwarding for all your Ansible-managed hosts at once.

    Now you can go on executing your playbook and should be able to clone the repository on the remote host.

    To make it even easier, we can add a task to load the ssh-key before executing the other tasks in the playbook. For this, add the local host to your Ansible inventory:

    1
    2
    [local]
    local_machine ansible_connection=local ansible_host=localhost
    

    Now we can add a small shell task to load the ssh-key:

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    ---
    - hosts: local
    - name: load ssh key
      shell: |
          ssh-add ~/.ssh/id_rsa
    
    - hosts: webserver
      tasks:
          - name: Ensure repo is up-to-date
            git:
                repo: git@github.com/ntlx/my-private-repo.git
                dest: repos/my-private-repo
    

    When you now execute the playbook, you shouldn’t need to load the ssh-key before.

    Guest Post on opensource.com: “Try this vi setup to keep and organize your notes”

    Juni 19, 2018 9:14 pm Veröffentlicht von

    Today my first blog post on opensource.com has been published, please have a look at it if your are, similar to myself, interested in an easy, intuitive, synchronized way to keep your notes.

    You can find it on the opensource.com blog or just by following this link.

    Thanks to the opensource.com team for collaboration and editing, I hope I will get the chance to write another one soon!