Category: kubernetes

  • Murphy’s Law – How to stall your Kubernetes enterprise rollout.

    Murphy’s Law – How to stall your Kubernetes enterprise rollout.

    In the world of software development, Murphy’s law holds an unassailable truth: Anything that can go wrong, will go wrong. As a proud member of this masochistic club, you might be looking for innovative ways to stall your Kubernetes enterprise rollout. Maybe you want to add a little chaos to your routine CI/CD workflow, or perhaps you’re just a thrill-seeker who loves the high stakes game of orchestration roulette. Either way, you’ve come to the right place. Sit back, relax, and let us guide you through the delightful maze of missteps and detours that will ensure your Kubernetes enterprise rollout is anything but a walk in the park.

    Ah, Kubernetes! The open-source platform that’s become the equivalent of a Hollywood blockbuster in the tech world. It’s like the Iron Man of container orchestration, bringing together an array of superpowers including automation, scaling, and management of container deployment. Enterprises are lining up to get their tickets, excited by the promises of streamlined application deployment. But before you go head over heels for Kubernetes, remember, even Iron Man had his quirks. Navigating the CI/CD waterfall can sometimes feel more like a rollercoaster ride without a seatbelt. So before you charge headfirst into your enterprise rollout, take a moment to consider Murphy’s Law – anything that can go wrong, will go wrong. So buckle up, my friends, it’s going to be a wild ride.

    This Photo by Unknown Author is licensed under CC BY-NC

    Indeed, Kubernetes is a boon for developers, cloud-native architects, and business owners alike. Its versatility and flexibility can make you feel like a superhero orchestrating seamless deployments. But when it comes to deploying and scaling in Enterprise data centers, Kubernetes might just swap its Iron Man suit for a Godzilla costume, spawning fresh challenges born out of its cloud-native architecture. This transition can lead to excessive mental gymnastics as you grapple with these new beasts of burden. So, if you’re feeling like a deer caught in the headlights, staring down the Kubernetes-python poised to gobble up your Enterprise applications, fear not! This blog is your sanctuary, your guide, your ‘how-to-tame-your-dragon’ manual. Stay with us, as we venture into the labyrinth of Kubernetes deployment and come out the other side grinning. 🙂

    Let’s dive into the 10 ways you might unintentionally stall your enterprise Kubernetes rollout, and inadvertently send your organization spiraling back to the ‘golden age’ of monolithic architecture:

    1. Do Not Plan Your Deployment: Some may argue that the beauty of Kubernetes lies in its simplicity, and indeed, the internet is abundant with blogs and videos promoting the notion that the deployment process is a walk in the park. Following such advice without investing time in understanding your unique use case could be a significant pitfall. Kubernetes deployments require thoughtful planning, taking into account the intricacies of workload requirements, resource allocation, and network architecture. The idea of “Kubernetes is the easy button for everything” is a perilous assumption that can easily derail your enterprise rollout. Always remember, while Kubernetes does a spectacular job in many aspects, it’s not a one-size-fits-all solution for every enterprise problem.

    This Photo by Unknown Author is licensed under CC BY-SA

    2. Avoid Using Certified Kubernetes Distributions: Now this one’s a head-scratcher, isn’t it? Here’s the thing, though: Kubernetes is powerful, flexible, and can be customized to a dizzying degree. However, this does not mean you should do everything from scratch. Consider this – why would you build your car when you can buy a perfectly good one off the lot? Certified Kubernetes distributions, like Red Hat OpenShift or VMware Tanzu, come with the assurance of being properly configured, tested, and meeting industry standards. They’re like your ready-to-drive cars, offering robust features and world-class support. By choosing to bypass these options, you’re essentially signing up for unnecessary headaches that could easily stall your enterprise rollout. Remember, Kubernetes is a tool, not an ideology. There’s no virtue in unnecessary complexities.

    Image from CNCF landscape

    3. Do NOT Implement Security Best Practices: This one’s a classic misstep in the tech world. Yes, Kubernetes is inherently secure, but that doesn’t mean it’s invincible. If you’re looking to stall your enterprise rollout, then by all means, ignore security best practices. However, if you’re keen on a smoothly functioning system, pay close attention to security measures like access control, network segmentation, and encryption. It’s akin to leaving your car unlocked in a crowded parking lot — sure, it might have an immobilizer and alarm system, but why invite trouble? Access control ensures only authorized personnel can interact with your Kubernetes clusters, network segmentation limits the blast radius of potential breaches, and encryption keeps your sensitive data safe in transit and at rest. Failing to implement these measures is like leaving the keys in your car with the engine running – a surefire way to invite mischief. Remember, in the world of Kubernetes deployments, security is not an afterthought, it’s a primary driver of successful CI/CD pipelines and enterprise rollouts.

    Image courtesy - https://www.google.com/url?sa=i&url=https%3A%2F%2Fsnyk.io%2Flearn%2Fcloud-application-security%2F&psig=AOvVaw0cLWWp0MtGNoPo1idw-iL7&ust=1691737538095000&source=images&cd=vfe&opi=89978449&ved=0CBIQjhxqFwoTCPCrh8vD0YADFQAAAAAdAAAAABAE

    4. Forget about Using CI/CD Pipelines: There’s a certain masochistic charm in choosing not to use CI/CD pipelines in your enterprise rollout. After all, who needs automation when you can manually deploy your applications, right? CI/CD pipelines, or Continuous Integration/Continuous Deployment pipelines, are like that studious classmate who always double-checks their work before submitting it – they automate the deployment process and ensure that all changes are thoroughly examined and validated before entering the production environment. If you’re a fan of chaos and unpredictability (and potentially stalling your Kubernetes enterprise rollout), then by all means, go ahead and give CI/CD pipelines a pass. However, if you value efficiency, reliability, and sanity, incorporating CI/CD pipelines into your operations could be a game-changer. They ensure a streamlined, error-free process that keeps your applications updated and secure, allowing your team to focus on what truly matters – building and improving your products. But hey, if you’re in the market for a bit of pandemonium, feel free to ignore this advice!

    image courtesy - https://devrant.com/rants/1535091/ci-cd-in-a-nutshell

    5. Visibility/Observability, what’s that?: There’s something rather intriguing about stumbling in the dark, isn’t there? For those of you who enjoy a good surprise, why not apply this approach to your Kubernetes deployment? Think about it, with no comprehensive monitoring solution in place, every day is like a thrilling game of hide-and-seek with your application’s performance, capacity, and availability. However, if you (like most sane people) prefer to know what’s happening under the hood, it’s time to incorporate a robust monitoring solution into your Kubernetes enterprise rollout. Think of it as a reliable co-pilot that keeps an eye on the road while you’re busy steering the ship. It helps you identify potential roadblocks or speed bumps, ensuring your journey toward a successful enterprise rollout is as smooth as possible. So go ahead, embrace the unknown, or better yet, ensure your unknowns are known with a comprehensive monitoring solution. But remember, no pressure; after all, it’s only your Kubernetes deployment we’re talking about here!

    image courtesy - https://linkedin.github.io/school-of-sre/level101/metrics_and_monitoring/observability/

    6. Don’t care about Config Management Tools: If you’re fond of unpredictability and enjoy the thrill of variance, throwing caution to the wind when it comes to config management could be your next adrenaline spike! Who needs tools like Ansible or Puppet that automate the configuration of your Kubernetes deployment and ensure consistent settings across your environment? Why make life easier and your enterprise rollout smoother when you can indulge in the chaotic symphony of inconsistency? Sure, these tools can simplify the management of your Kubernetes configuration, reduce errors, and ensure uniformity across your deployment, but where’s the fun in that? So sit back, relax, and let the inconsistencies rollick through your deployment, because who wouldn’t love a good configuration surprise?

    image courtesy - https://www.atlassian.com/microservices/microservices-architecture/configuration-management

    7. Forget about Disaster Recovery: If you’re the type who loves to live on the edge, why not take a leap of faith with your Kubernetes rollout too? After all, implementing disaster recovery measures like backup and recovery procedures is like carrying an umbrella all the time just because it might rain. Sure, these measures could prevent your enterprise from figuratively getting drenched in the event of an unexpected outage or data loss, but what’s a little water, right? Having a disaster recovery plan could mean the difference between a minor hiccup and a full-fledged organizational crisis during a catastrophe, but let’s face it, who doesn’t love a little game of Russian Roulette with their Kubernetes deployment? So, go ahead and roll the dice. After all, disaster recovery is just for those who aren’t fans of suspense, right?

    image courtesy - https://www.sungardas.com/en-us/blog/how-to-create-a-dr-plan-you-can-be-confident-in/

    8. Train Your Staff (or Don’t): Now, here’s a real knee-slapper: education. Nothing quite like seeing your team scramble around like a bunch of cats on a hot tin roof because they don’t know their Pods from their Nodes. Who needs well-trained staff, conversant with Kubernetes best practices, when you can bask in the glorious pandemonium of mismanaged deployments instead? Sure, giving your employees the necessary skills to effectively manage and operate your Kubernetes deployment might lead to fewer issues, greater efficiency, and a more successful enterprise rollout. But let’s be real, why stifle the potential theatre of the absurd that could result from untrained staff wrestling a mammoth like Kubernetes? Life is a stage, after all, and in your Kubernetes drama, training is just too mainstream a script. So, sit back, grab some popcorn, and enjoy the show!

    image courtesy - https://www.makemebetter.net/learning-to-go-with-the-flow/

    9. Live in the Past: Here’s a revolutionary idea – rolling with the times. You could, if you’re feeling particularly adventurous, actually stay up-to-date with the latest Kubernetes releases and security patches. That, of course, would imply that you’re interested in ensuring your deployment operates with the latest features and security updates. But hey, who doesn’t love a little nostalgia? Sure, you could prioritize keeping your enterprise rollout in line with the newest, slickest versions of Kubernetes, ensuring that your CI/CD pipelines are as cutting-edge as they come, but isn’t there a certain charm in running your enterprise on an antiquated version that’s as outdated as a floppy disk in an AI lab? After all, cybersecurity threats, outdated functionalities, and inefficiencies are just minor speed bumps on the road of enterprise rollouts. So, why not kick back, ignore those pesky update notifications, and let your Kubernetes deployment bask in the warm glow of obsolescence? Just remember – living in the past is only fun until the ghosts of security vulnerabilities and outdated features come knocking on your door.

    10. Embrace Impermanence (non-persistence): In the grand scheme of things, isn’t Kubernetes is supposed to be ephemeral? Why should your data be any different? Go ahead, live dangerously. Don’t bother with planning for data persistence in your Kubernetes rollout. Imagine the thrill of living on the edge, knowing that you could lose all your data the moment a pod goes down or the system crashes. Sure, you could use the Kubernetes Persistent Volume (PV) and Persistent Volume Claim (PVC) architecture to ensure your data survives even when your pods don’t, but where’s the fun in that? Data persistence is so pedestrian. Remember, the goal here is to stall your Kubernetes enterprise rollout, not to make it robust, resilient, and reliable. So, go ahead, and throw caution (and your data) to the wind. It’s only important business information after all, right?

    image courtesy - https://cloudtweaks.com/2016/11/4-cloud-tools-help-business-save-money/

    But hey, here’s a novel idea – what if you actually wanted to succeed in your cloud-native strategy? I know, I know, it sounds a bit radical given our prior conversation. But bear with me. For those of you who enjoy sailing smoothly on the seas of enterprise IT, without the thrill of hitting every possible iceberg, Dell has created a glorious solution. A tool, that’s as much a life preserver as it is a nautical chart, guiding you safely through the treacherous waters of Kubernetes enterprise rollouts. This magic wand is called the Container Storage Modules (CSM). 

    https://dell.github.io/csm-docs/docs/

    This isn’t just any tool – it’s your co-pilot on the journey to a seamless Kubernetes implementation. It’s like having a Swiss army knife for enterprise data management. The CSM ensures that your data persistence strategies are as solid as a rock, ensuring that no pod crash or system failure can sweep your data into the abyss. With CSM, you can laugh in the face of data loss, secure in the knowledge that your enterprise information is safe and sound. So, for the daredevils who actually like to succeed in their endeavors, the Dell Technologies CSM is the perfect tool to ensure your Kubernetes enterprise rollout is as smooth and trouble-free as a hot knife through butter.

    I hope this post proves helpful, regardless of which direction you choose for your enterprise cloud journey. If you’re inclined to thrill and enjoy the odd game of Russian roulette with your data, you now have some innovative strategies to stall your Kubernetes rollout. However, if your preference is smooth as a jazz tune and your data as secure as Dell’s Project Fort Zero, then Dell’s Container Storage Modules (CSM) is the tool you need. The CSM is your beacon in the foggy world of Kubernetes enterprise rollout, ensuring that no data loss or system failure can derail your cloud-native strategy. It’s your data’s best friend, your enterprise’s lifeline, and your ticket to a successful Kubernetes implementation.

    Enjoy the journey, and remember – with the right tools and strategies, Murphy’s Law doesn’t stand a chance!

  • Red Hat OpenShift – Add SSH Keys to Cluster (After Deployment)

    Red Hat OpenShift – Add SSH Keys to Cluster (After Deployment)

    Part of my job is to demonstrate the Red Hat OpenShift integration with Dell Technologies’ portfolio. Most of the time I repurpose my OCP infrastructure and re-install the cluster. This means using the same Bastion host to manage the new OCP cluster. There have been a couple of instances where I forgot to include bastion host SSH keys in the OCP installation and because of that, I couldn’t log in to the OCP cluster nodes.

    By default, RH CoreOS gets installed with a single user (core) with the option to add SSH keys at the install time. Most of the tasks in the RH OCP environment are done from the bastion/service node without the need to log in directly on the OCP nodes. But in some cases, you might find it useful to have SSH access to OCP nodes. In my case, it was for configuring the iSCSI and multipath on OCP nodes (for CSI configuration)

    Installing SSH keys post OCP installation is a bit tricky and hence the purpose of this blog. I hope this helps fellow OCP architects (and as a reference for me as well).

    To start with below is the high-level Red Hat OCP setup I have created. My test OCP cluster (version 4.8.x) is having 3 nodes, which are acting as both master and worker.

    Logging into the RH OCP cluster from bastion/service node

    Before you get started make sure you’re able to execute OC commands from the bastion/service node. If you’re getting an error (like below) then make sure you’re logged into the newly created cluster.

    RH OCP – Login Error

    For connecting the service node to the RH OCP cluster you will need an API token. For generating the API token, log into the RH OCP UI –> Click on User Name (top right corner) –> Click on Copy Login Command.

    This will open a new window. Click on the Display Token link. Copy the oc login command and run it on the service node.

    RH OCP – Copy Login Command
    RH OCP – Log into the OCP Cluster

    Update RH OCP SSH Keys

    In RH OCP there are 2 MachineConfigs (99-master-ssh and 99-worker-ssh) that handle the SSH key management. You can list those using the below command. If you had given the SSH keys while installing RH OCP then it will get registered in these MachineConfigs

    [root@ocp-svc ~]# oc get machineconfig | grep "ssh"
    99-assisted-installer-master-ssh 3.1.0 54d
    99-master-ssh 3.2.0 54d
    99-worker-ssh 3.2.0 54d

    First, we will start with master nodes.

    The next step is to download the MachineConfig as YAML to update the SSH keys. You can run the below command to download the machine config object. In this case, I am getting the configuration from the master server.

    [root@ocp-svc ~]# oc get mc 99-master-ssh -o yaml > 99-master-ssh.yaml

    Copy the SSH keys from the service/bastion node. You can generate the new keys (if needed using the ssh-keygen command). By default, SSH keys are stored on the /root/.ssh/id_rsa.pub location.

    Edit the downloaded 99-master-ssh.yaml file and append the copied SSH key in the passwd section of the yaml file (as shown below) and save the file. Make sure you follow the YAML syntax while editing the file.

        passwd:
          users:
          - name: core
            sshAuthorizedKeys:
            - <existing SSH key>
            - <your new SSH key>
      fips: false
      kernelType: ""
      osImageURL: ""
    

    Then run the following command to apply the new MachineConfig file with the updated SSH key. This step might restart your nodes (one by one).

    [root@ocp-svc ~]# oc apply -f 99-master-ssh.yaml

    At this stage, you will be able to log into the master nodes. You’ll need to run the same procedure again for the worker nodes by updating the 99-worker-ssh MachineConfig.

    Additionally, if you’re reusing the bastion/service node then make sure you remove the old entries from the /root/.ssh/known_hosts file.

    I hope this article helps everyone.

  • Fix Error – Failed to reload sysctl: sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-ip6tables

    Fix Error – Failed to reload sysctl: sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-ip6tables

    I have been working with Ansible for automating Kubernetes deployment using CentOS VM templates. As a pre-requisite we need to ensure net.bridge.bridge-nf-call-iptables and net.bridge.bridge-nf-call-ip6tables is set to 1.

    I created below tasks in my Ansible role playbook.

    # Set net.bridge.bridge-nf-call-ip6tables value to 1 all K8S cluster nodes
      - name: ensure net.bridge.bridge-nf-call-ip6tables is set to 1
        sysctl:
         name: net.bridge.bridge-nf-call-ip6tables
         value: 1
         state: present
       
    # Set net.bridge.bridge-nf-call-iptables value to 1 all K8S cluster nodes
      - name: ensure net.bridge.bridge-nf-call-iptables is set to 1
        sysctl:
         name: net.bridge.bridge-nf-call-iptables
         value: 1
         state: present
       

    But when I executed this playbook I got below error

    fatal: [prod-k8s-master01]: FAILED! => {"changed": false, "msg": "Failed to reload sysctl: sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-ip6tables: No such file or dire                                                ctory\nsysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-iptables: No such file or directory\n"}
    fatal: [prod-k8s-worker01]: FAILED! => {"changed": false, "msg": "Failed to reload sysctl: sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-ip6tables: No such file or dire                                                ctory\nsysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-iptables: No such file or directory\n"}

    After lots of reading and researching I found that I did not escalate the privileges on in my main YML file. After adding Become: yes in the main YML resolved my issue. Below is the syntax of my main playbook.

    - hosts: all
      gather_facts: false
      become: yes
      vars_files:
        - answerfile.yml

    Sometimes common mistakes are the most time consuming because we take it for granted.

    Note that in my example I am using CentOS.

  • Automating Kubernetes deployment on VMs using Ansible

    Automating Kubernetes deployment on VMs using Ansible

    In this post, we will discuss automating Kubernetes deployment using Ansible.

    In my example, I have used CentOS VMs (on VMware) for deploying Kubernetes. But technically Kubernetes deployment steps don’t differ irrespective of the platform you use.

    Before getting started to make sure you have

    • Ansible server up and running on the network. Also, make sure Ansible can reach the VMware environment.
    • Make sure you’ve added Ansible server SSH authentication keys into VMware virtual machine before converting the same into the template. Follow this blog post for steps.

    Once you have the pre-requisites in place follow the below steps.

    Step 1 – Clone my GitHub repository which consists of required playbooks and instructions.

    [root@alb-ansible dw-pm-csi]# git clone https://github.com/waghmaredb/ansible-k8s
    Cloning into 'ansible-k8s'…
    remote: Enumerating objects: 41, done.
    remote: Counting objects: 100% (41/41), done.
    remote: Compressing objects: 100% (40/40), done.
    remote: Total 41 (delta 12), reused 0 (delta 0), pack-reused 0
    Unpacking objects: 100% (41/41), done.
    [root@alb-ansible dw-pm-csi]# cd ansible-k8s/
    [root@alb-ansible ansible-k8s]# ls
    k8s-deployment.yml README.md

    Step 2 – Edit k8s-deployment.yml file and edit below lines from VARS

    common environment details
    #ntp_server: - Replace with your NTP server IP/hostname
    domain: "" - Replace with your DOMAIN NAME
    dns_server: - Replace with your DNS server IP/hostname
    vmware environment details
    vcenter_ip: - Replace with your vCenter server IP/hostname
    vcenter_username: - Replace with vCenter admin account username
    vcenter_password: - Replace with vCenter admin account password
    vmware_datacenter: - Replace with VMware datacenter you want to use
    vmware_cluster: - Replace with VMware cluster you want to use
    vm_network: "" - Replace with VM network you want kubernetes VMs to connect
    k8s_vm_folder: - Replace with VM folder in which you want to place kubernetes VMs
    k8s_template_name: - Replace with VMware CentOS template name
    K8S environment details
    k8s_master_ip: 192.168.172.100 - Replace IP address with kubernetes master server IP address you want to use
    k8s_network_netmask: 255.255.255.0 - Replace subnet mask with netmask of kubernetes network
    k8s_network_gateway: 192.168.172.1 - Replace gateway with kubernetes network gateway
    k8s_node1_ip: 192.168.172.101 - Repalce IP address with kubernetes node IP address
    #k8s_node2_ip: 192.168.1.102
    #k8s_node3_ip: 192.168.1.103
    #k8s_node4_ip: 192.168.1.104
    #k8s_node5_ip: 192.168.1.105
    #k8s_node6_ip: 192.168.1.106
    #k8s_node7_ip: 192.168.1.107
    #k8s_node8_ip: 192.168.1.108

    Step 3 – Edit the /etc/ansible hosts file and insert the Kubernetes environment details. Make sure IP address details are inline with your Kubernetes environment

    [kube_cluster1]
    k8s-master ansible_host=192.168.172.100 ansible_user=root
    worker1 ansible_host=192.168.172.101 ansible_user=root
    worker2 ansible_host=192.168.172.102 ansible_user=root
    worker3 ansible_host=192.168.172.103 ansible_user=root
    worker4 ansible_host=192.168.172.104 ansible_user=root
    
    [master]
    k8s-master ansible_host=192.168.172.100 ansible_user=root
    
    [worker]
    worker1 ansible_host=192.168.172.101 ansible_user=root
    worker2 ansible_host=192.168.172.102 ansible_user=root
    worker3 ansible_host=192.168.172.103 ansible_user=root
    worker4 ansible_host=192.168.172.104 ansible_user=root

    Step 4 – Run the k8s-deployment.yml playbook.

  • What is Container Storage Integration (CSI) and Why now?

    What is Container Storage Integration (CSI) and Why now?

    Containers are everywhere and they are here to stay. They are great level-playing ground to break the infrastructure dependency and allow developers to release their code to any environment.

    Containers also help customers to operate at greater scales with ability to quickly scaling up and down, patching with disruptions, withstand infrastructure component failures, moving easily from on-premises to public clouds, etc.

    As per the survey from sysdig lifespan of containers and container images is also very short.

    At this stage of the popularity of containers there are two thought processes in the container fan club – Persistent or Non-Persistent Containers

    If you explore docker hub top downloads you’ll notice that 7/10 top downloads require data persistence (snippet below)

    Let’s understand persistent containers in more details.

    Prior to Container Storage Integration CSI, Kubernetes provided in-tree (ie as part of the core code) plugins to support volumes but that posed a problem in that storage vendors had to align to the Kubernetes release process to fix a bug or to release new features among other problems. This also means every storage vendor had their own process to present volumes to Kubernetes.

    This heterogeneous non-standard integrations were one of the biggest reasons why CSI was created. CSI was developed as a standard for exposing block and file storage storage systems to containerized workloads on Container Orchestration Systems (COs) like Kubernetes. With the adoption of the Container Storage Interface (CSI), the Kubernetes volume layer becomes truly extensible. Using CSI, third-party storage providers like DellEMC can write and deploy plugins exposing new storage systems in Kubernetes without ever having to touch the core Kubernetes code. This gives Kubernetes users more options for storage and makes the system more secure and reliable. Also this approach makes sure that every vendor has standard way of interacting with Kubernetes.

    With CSI Kubernetes supports Persistent Volumes (PV). PVs life-cycle independent of any Kubernetes POD. Kubernetes supports 2 ways to provision PVs

    • Static – Admin Pre-provisions / creates a number of PVs
    Static PV provisioning
    • Dynamic – Cluster “automatically” provisions a volume
    Dynamic PV provisioning

    No matter which is the method of PV provisioning it can support varying properties such as performance, QOS, backup policies, etc. These properties are defined by StorageClass

    There are 3 access modes which are supported on PV. Storage volume cannot be mounted simultaneously in more than one access mode.

    1. ReadWriteOnce (RWO) – Volume can be mounted as ready-write by a single node
    2. ReadOnlyMany (ROX) – Volume can be mounted read-only by many nodes
    3. ReadWriteMany (RWX) – Volume can be mounted as read-write by many nodes

    Below is the summary of persistence

    DellEMC CSI Support

    DellEMC understands that that Enterprise applications require persistent storage. As of now (Nov 2019) DellEMC supports CSI plugins for below storage arrays

    Below are few documents around DellEMC CSI integration

    More blogs on CSI coming up 🙂

  • Installing Kubernetes on CentOS

    Installing Kubernetes on CentOS

    Part of my job is to talk about the latest geeky technologies and many times I also have to demonstrate the same – Kind of “Show me” discussions.

    When I started working on getting my hands dirty on Kubernetes (aka K8S) I faced many issues to get started. Now I am at the level where deploying K8S isn’t a big deal at all. The reason I am writing this blog is that often more than not I always get into discussions where someone is just starting with the K8S journey and has the same queries and questions which I also had. Hopefully, this summary will help people to get started with K8S.

    Before I get started it’s important to understand the K8S lingo 🙂 This will help understand the implementation steps. Also, note that the purpose of this page is not to re-iterate the K8S components and architecture. It’s purely intended to list the steps o have hassle-free K8S deployment

    Make sure that the VMware template which will be used has Ansible master server SSH keys added before you convert the VM image to the template. I have already documented this process of enabling SSH-based authentication in this blog

    Part 1 – Dependencies

    Below are the list of dependencies which needs to be installed on all the K8S nodes (master and worker)

    • Disable SELinux
    sudo setenforce 0
    sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
    • Turnoff swap (also remove swap entry from /etc/fstab)
    swapoff -a
    yum -y install docker
    systemctl enable docker
    systemctl start docker
    systemctl status docker
    • Ensure net.bridge.bridge-nf-call-ip6tables is set to 1
    • Ensure net.bridge.bridge-nf-call-iptables is set to 1
    sudo bash -c 'cat <<EOF >  /etc/sysctl.d/k8s.conf
    net.bridge.bridge-nf-call-ip6tables = 1
    net.bridge.bridge-nf-call-iptables = 1
    EOF'
    • Add Kubernetes YUM repository
    cat <<EOF > /etc/yum.repos.d/kubernetes.repo
    [kubernetes]
    name=Kubernetes
    baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
    enabled=1
    gpgcheck=1
    repo_gpgcheck=1
    gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
    EOF
    • Install kubelet (I installed version 1.14)
    • install kubeadm (I installed version 1.14)
    • Start kubelet service
    yum -y install kubelet kubeadm

    Below listed dependencies are only for K8S master

    • Install kubectl
    yum -y install kubectl
    kubectl version

    Part 2 – Kubernetes Master

    Below listed steps are for configuring K8S Master

    • Initialize the cluster using below command
    kubeadm init --pod-network-cidr=10.244.0.0/16 >> cluster_initialized.txt
    • Create ~/.kube directory (chmod 0755)
    • Copy admin.conf to user’s kube config
    cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
    • Install Pod network. In my case I have used Flannel, but you can choose relevant cluster networking from certified options from this link.
    kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml >> pod_network_setup.txt

    At this moment your K8S master is installed and configured. Next step is to configure worker nodes and add them into the K8S cluster

    Part 3 – Kubernetes Worker

    Final part is to have worker nodes configured and add them in K8S cluster. This steps involves running commands on Master and Worker nodes.

    • Master node – For adding worker nodes into the K8S cluster we first need to get the join command from the master server. Run the below command on Master server
    kubeadm token create --print-join-command
    • Note/copy the join command output. We need to run this join command on all worker nodes.

    Finally run below command on the K8S Master. If everything was successful then you should see list of all the nodes (Master and Worker) of your K8S cluster.

    kubectl get nodes

    This concludes K8S installation and configuration 🙂