home.social

#k9s — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #k9s, aggregated by home.social.

  1. Топ-8 опенсорс‑инструментов, которые необходимы разработчику в кубере

    Open source инструменты удобны для разработчика: настраиваешь их под себя и не зависишь от чужих правил, ценников и внезапных ограничений. Плюс вокруг них обычно есть живая документация и комьюнити — проблемы и решения редко остаются «в вакууме». Собрали с командой R&D список инструментов, которыми сами пользуемся ежедневно. В подборке — опенсорсные инструменты для разных ситуаций: от работы с Kubernetes и контейнерными реестрами до тестирования API, проверки чужих репозиториев и runtime‑наблюдения за безопасностью контейнеров.

    habr.com/ru/companies/pt/artic

    #cybersecurity #backend #runtime #code_review #freelens #k9s #skopeo #bruno #zed

  2. Топ-8 опенсорс‑инструментов, которые необходимы разработчику в кубере

    Open source инструменты удобны для разработчика: настраиваешь их под себя и не зависишь от чужих правил, ценников и внезапных ограничений. Плюс вокруг них обычно есть живая документация и комьюнити — проблемы и решения редко остаются «в вакууме». Собрали с командой R&D список инструментов, которыми сами пользуемся ежедневно. В подборке — опенсорсные инструменты для разных ситуаций: от работы с Kubernetes и контейнерными реестрами до тестирования API, проверки чужих репозиториев и runtime‑наблюдения за безопасностью контейнеров.

    habr.com/ru/companies/pt/artic

    #cybersecurity #backend #runtime #code_review #freelens #k9s #skopeo #bruno #zed

  3. Топ-8 опенсорс‑инструментов, которые необходимы разработчику в кубере

    Open source инструменты удобны для разработчика: настраиваешь их под себя и не зависишь от чужих правил, ценников и внезапных ограничений. Плюс вокруг них обычно есть живая документация и комьюнити — проблемы и решения редко остаются «в вакууме». Собрали с командой R&D список инструментов, которыми сами пользуемся ежедневно. В подборке — опенсорсные инструменты для разных ситуаций: от работы с Kubernetes и контейнерными реестрами до тестирования API, проверки чужих репозиториев и runtime‑наблюдения за безопасностью контейнеров.

    habr.com/ru/companies/pt/artic

    #cybersecurity #backend #runtime #code_review #freelens #k9s #skopeo #bruno #zed

  4. Топ-8 опенсорс‑инструментов, которые необходимы разработчику в кубере

    Open source инструменты удобны для разработчика: настраиваешь их под себя и не зависишь от чужих правил, ценников и внезапных ограничений. Плюс вокруг них обычно есть живая документация и комьюнити — проблемы и решения редко остаются «в вакууме». Собрали с командой R&D список инструментов, которыми сами пользуемся ежедневно. В подборке — опенсорсные инструменты для разных ситуаций: от работы с Kubernetes и контейнерными реестрами до тестирования API, проверки чужих репозиториев и runtime‑наблюдения за безопасностью контейнеров.

    habr.com/ru/companies/pt/artic

    #cybersecurity #backend #runtime #code_review #freelens #k9s #skopeo #bruno #zed

  5. @thomasmey You are right, but starting a debug container does not get the same mounts/secrets/environment variables as the to debug pod. This is why I started using my #k9s plugin. But you are right, it is also possible to use 'kubectl debug' but in a different way.

  6. #K9s Plugins: Debug Kubernetes Like a Pro

    Debugging #Kubernetes workloads is painful, recreating volumes, secrets and configmaps by hand every time. I built a #k9s plugin that spins up a debug pod with everything pre-mounted automatically.

    One keyboard shortcut and you're in a shell with the full container config.

    My blog post: blog.bitfoo.de/posts/k9s-plugi

    #DevOps #k8s #Kubernetes #SRE #CloudNative #Linux #OpenSource #Containers #Homelab #PlatformEngineering #Docker

  7. 🖥️ #lazyssh – Terminal-based #SSH Manager inspired by #lazydocker & #k9s #Go #opensource #devops #cli #sysadmin

    📜 Reads & displays servers from ~/.ssh/config in a scrollable TUI list
    🔍 Fuzzy search by alias, IP or tags for quick server navigation
    📌 Pin/unpin favorite servers to keep them at the top
    🏷️ Tag servers (prod, dev, test) for easy filtering & sorting
    🔗 Advanced port forwarding: LocalForward, RemoteForward, DynamicForward

    🧵 👇

  8. Wow, look what cool thing I found – K9s (k9scli.io). I'm just starting to get familiar with Kubernetes, managed to deploy my test API (Symfony 7.3) server with automation through GitHub Actions, and now with K9s it's much easier to check logs, statuses, and just navigate through the pods.

    There are so many interesting tools out there that I still don’t know about 😍

    #kubernetes #k8s #automation #devops #github #githubactions #symfony #k9s

  9. was walking a coworker through something in k9s and I told them to type “colon deployments” and my partner, who can only hear my side of the conversation, messages me “colon deployments, isn’t that just taking a shit?” 😂

    #kubernetes #k8s #k9s

  10. Локальная разработка с Kubernetes. Немного танцев с бубном

    На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т.д. Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую-то ветку с разрабатываемой фичей или исправлением бага в ветку, которая “привязана” к окружению и дальше наш код деплоится в кластер. Думаю, для многих - это уже стандартная история. Давайте представим, что нужно сделать задачу, относящуюся к какому-нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на “боевые”. Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы “ковыряем” и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:

    habr.com/ru/articles/926556/

    #kubernetes #minikube #telepresence #k9s #микросервисы #разработка #kubectl

  11. Локальная разработка с Kubernetes. Немного танцев с бубном

    На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т.д. Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую-то ветку с разрабатываемой фичей или исправлением бага в ветку, которая “привязана” к окружению и дальше наш код деплоится в кластер. Думаю, для многих - это уже стандартная история. Давайте представим, что нужно сделать задачу, относящуюся к какому-нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на “боевые”. Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы “ковыряем” и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:

    habr.com/ru/articles/926556/

    #kubernetes #minikube #telepresence #k9s #микросервисы #разработка #kubectl

  12. Локальная разработка с Kubernetes. Немного танцев с бубном

    На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т.д. Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую-то ветку с разрабатываемой фичей или исправлением бага в ветку, которая “привязана” к окружению и дальше наш код деплоится в кластер. Думаю, для многих - это уже стандартная история. Давайте представим, что нужно сделать задачу, относящуюся к какому-нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на “боевые”. Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы “ковыряем” и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:

    habr.com/ru/articles/926556/

    #kubernetes #minikube #telepresence #k9s #микросервисы #разработка #kubectl

  13. Локальная разработка с Kubernetes. Немного танцев с бубном

    На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т.д. Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую-то ветку с разрабатываемой фичей или исправлением бага в ветку, которая “привязана” к окружению и дальше наш код деплоится в кластер. Думаю, для многих - это уже стандартная история. Давайте представим, что нужно сделать задачу, относящуюся к какому-нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на “боевые”. Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы “ковыряем” и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:

    habr.com/ru/articles/926556/

    #kubernetes #minikube #telepresence #k9s #микросервисы #разработка #kubectl

  14. I'm using k9s to view my Kubernetes objects.

    One can use K9S_FEATURE_GATE_NODE_SHELL=true| to enable node shell.

    Link: k9scli.io/topics/config/

    cc: @bycx

    #k9s #livingK8S

  15. I'm using k9s to view my Kubernetes objects.

    One can use K9S_FEATURE_GATE_NODE_SHELL=true| to enable node shell.

    Link: k9scli.io/topics/config/

    cc: @bycx

    #k9s #livingK8S

  16. I'm using k9s to view my Kubernetes objects.

    One can use K9S_FEATURE_GATE_NODE_SHELL=true| to enable node shell.

    Link: k9scli.io/topics/config/

    cc: @bycx

  17. I'm using k9s to view my Kubernetes objects.

    One can use K9S_FEATURE_GATE_NODE_SHELL=true| to enable node shell.

    Link: k9scli.io/topics/config/

    cc: @bycx

    #k9s #livingK8S

  18. I'm using k9s to view my Kubernetes objects.

    One can use K9S_FEATURE_GATE_NODE_SHELL=true| to enable node shell.

    Link: k9scli.io/topics/config/

    cc: @bycx

    #k9s #livingK8S

  19. Flux monorepo layout

    Flux, or FluxCD, is a "set of continuous and progressive delivery solutions for Kubernetes that are open and extensible" and is my preferred way to do "GitOps" in my Kubernetes clusters. I like Flux because it handles Helm extremely well (I'm a big fan of Helm) and allows me to have a simple fallback if something goes wrong. In this post, I will go through the process of

    dustinrue.com/2025/03/flux-mon

    #colima #fluxcd #helm #k9s #Kubernetes

  20. Flux monorepo layout

    Flux, or FluxCD, is a “set of continuous and progressive delivery solutions for Kubernetes that are open and extensible” and is my preferred way to do “GitOps” in my Kubernetes clusters. I like Flux because it handles Helm extremely well (I’m a big fan of Helm) and allows me to have a simple fallback if something goes wrong. In this post, I will go through the process of installing flux, k3s that can be used for testing and then creating a Flux project that adopts Flux’s documented monorepo design. I have also published a copy of the work detailed here to Github so you can use as a working starter for your own project.

    […]

    https://dustinrue.com/2025/03/flux-monorepo-layout/

    #colima #fluxcd #helm #k9s #Kubernetes

  21. OK, finally got the node back up again. I decided to just get a brand new #BeQuiet SFX PSU, to replace the old #SpeedCruiser Flex PSU and rebuild the node with otherwise the same hardware, into a spare #Silverstone SG13 case I have and it all works.

    Also discovered that the reason why HA wasn't working and none of my VMs I've set replication for didn't carry over to the healthy node was because I had forgotten to actually create a HA group on Proxmox and set the VMs to HA so... did that.

    Now I'm freaking wrestling with my
    #RKE2 #Kubernetes cluster to get it back up and running again, cos atm the cluster is littered with pods that are either Pending, Unknown or in a crash loop... which is always fucking fun. Also the cluster itself is kind of slow to respond (on #k9s)... which is concerning but I think has to do prolly with how its networking is setup.

    I'm still completely clueless honestly on what the "ideal" networking setup is for both Proxmox, and a Kubernetes cluster hosted on Proxmox. I'm still stuck with the defaults, for now, that is using the onboard nic on each Proxmox node for every single thing. The only customisation I've done was setting a bandwidth limit (on Proxmox)
    only for migration. #Homelab folks please feel free sending some suggestions my way, that is as dummy-friendly as possible :))

    RE:
    https://sakurajima.social/notes/a2e9fm36yg

  22. I've just merged a huge PR to my #Orked (O-tomated RKE Distribution - GREAT NAME I KNOW) that makes it easier than ever for anyone to set up a production-ready #RKE2 #Kubernetes cluster in their #homelab.

    With this collection of scripts, all you need to do is just provision the nodes required, including a login/management node, and run the scripts right from the login node to configure all of the other nodes to make up the cluster. This setup includes:

    - Configuring the Login node with any required or essential dependencies (such as
    #Helm, #Docker, #k9s, #kubens, #kubectx, etc.)

    - Setup passwordless
    #SSH access from the Login node to the rest of the Kubernetes nodes

    - Update the
    hosts file for strictly necessary name resolution on the Login node and between the Kubernetes nodes

    - Necessary, best practice configurations for all of the Kubernetes nodes including networking configuration, disabling unnecessary services, disabling swap, loading required modules, etc.

    - Installation and configuration of RKE2 on all the Kubernetes nodes and joining them together as a cluster

    - Installation and configuration of
    #Longhorn storage, including formatting/configuring their virtual disks on the Worker nodes

    - Deployment and configuration of
    #MetalLB as the cluster's load-balancer

    - Deployment and configuration of
    #Ingress #NGINX as the ingress controller and reverse proxy for the cluster - this helps manage external access to the services in the cluster

    - Setup and configuration of
    #cert-manager to obtain and renew #LetsEncrypt certs automatically - supports both #DNS and HTTP validation with #Cloudflare

    - Installation and configuration of
    #csi-driver-smb which adds support for integrating your external SMB storage to the Kubernetes cluster

    Besides these, there are also some other
    helper scripts to make certain related tasks easy such as a script to set a unique static IP address and hostname, and another to toggle #SELinux enforcement to on or off - should you need to turn it off (temporarily).

    If you already have an existing RKE2 cluster, there's a step-by-step guide on how you could use it to easily configure and join additional nodes to your cluster if you're planning on expanding.

    Orked currently expects and supports
    #RockyLinux 8+ (should also support any other #RHEL distros such as #AlmaLinux), but I am planning to improve the project over time by adding more #Linux distros, #IPv6 support, and possibly even #K3s for a more lightweight #RaspberryPi cluster for example.

    I've used this exact setup to deploy and manage vital services to hundreds of unique clients/organisations that I've become
    obsessed with sharing it to everyone and making it easier to get started. If this is something that interests you, feel free to check it out!

    If you're wondering what to deploy on a Kubernetes cluster - feel free to also check out my
    #mika helm chart repo 🥳

    🔗 https://github.com/irfanhakim-as/orked

    🔗 https://github.com/irfanhakim-as/charts

  23. I've just merged a huge PR to my #Orked (O-tomated RKE Distribution - GREAT NAME I KNOW) that makes it easier than ever for anyone to set up a production-ready #RKE2 #Kubernetes cluster in their #homelab.

    With this collection of scripts, all you need to do is just provision the nodes required, including a login/management node, and run the scripts right from the login node to configure all of the other nodes to make up the cluster. This setup includes:

    - Configuring the Login node with any required or essential dependencies (such as
    #Helm, #Docker, #k9s, #kubens, #kubectx, etc.)

    - Setup passwordless
    #SSH access from the Login node to the rest of the Kubernetes nodes

    - Update the
    hosts file for strictly necessary name resolution on the Login node and between the Kubernetes nodes

    - Necessary, best practice configurations for all of the Kubernetes nodes including networking configuration, disabling unnecessary services, disabling swap, loading required modules, etc.

    - Installation and configuration of RKE2 on all the Kubernetes nodes and joining them together as a cluster

    - Installation and configuration of
    #Longhorn storage, including formatting/configuring their virtual disks on the Worker nodes

    - Deployment and configuration of
    #MetalLB as the cluster's load-balancer

    - Deployment and configuration of
    #Ingress #NGINX as the ingress controller and reverse proxy for the cluster - this helps manage external access to the services in the cluster

    - Setup and configuration of
    #cert-manager to obtain and renew #LetsEncrypt certs automatically - supports both #DNS and HTTP validation with #Cloudflare

    - Installation and configuration of
    #csi-driver-smb which adds support for integrating your external SMB storage to the Kubernetes cluster

    Besides these, there are also some other
    helper scripts to make certain related tasks easy such as a script to set a unique static IP address and hostname, and another to toggle #SELinux enforcement to on or off - should you need to turn it off (temporarily).

    If you already have an existing RKE2 cluster, there's a step-by-step guide on how you could use it to easily configure and join additional nodes to your cluster if you're planning on expanding.

    Orked currently expects and supports
    #RockyLinux 8+ (should also support any other #RHEL distros such as #AlmaLinux), but I am planning to improve the project over time by adding more #Linux distros, #IPv6 support, and possibly even #K3s for a more lightweight #RaspberryPi cluster for example.

    I've used this exact setup to deploy and manage vital services to hundreds of unique clients/organisations that I've become
    obsessed with sharing it to everyone and making it easier to get started. If this is something that interests you, feel free to check it out!

    If you're wondering what to deploy on a Kubernetes cluster - feel free to also check out my
    #mika helm chart repo 🥳

    🔗 https://github.com/irfanhakim-as/orked

    🔗 https://github.com/irfanhakim-as/charts

  24. I've just merged a huge PR to my #Orked (O-tomated RKE Distribution - GREAT NAME I KNOW) that makes it easier than ever for anyone to set up a production-ready #RKE2 #Kubernetes cluster in their #homelab.

    With this collection of scripts, all you need to do is just provision the nodes required, including a login/management node, and run the scripts right from the login node to configure all of the other nodes to make up the cluster. This setup includes:

    - Configuring the Login node with any required or essential dependencies (such as
    #Helm, #Docker, #k9s, #kubens, #kubectx, etc.)

    - Setup passwordless
    #SSH access from the Login node to the rest of the Kubernetes nodes

    - Update the
    hosts file for strictly necessary name resolution on the Login node and between the Kubernetes nodes

    - Necessary, best practice configurations for all of the Kubernetes nodes including networking configuration, disabling unnecessary services, disabling swap, loading required modules, etc.

    - Installation and configuration of RKE2 on all the Kubernetes nodes and joining them together as a cluster

    - Installation and configuration of
    #Longhorn storage, including formatting/configuring their virtual disks on the Worker nodes

    - Deployment and configuration of
    #MetalLB as the cluster's load-balancer

    - Deployment and configuration of
    #Ingress #NGINX as the ingress controller and reverse proxy for the cluster - this helps manage external access to the services in the cluster

    - Setup and configuration of
    #cert-manager to obtain and renew #LetsEncrypt certs automatically - supports both #DNS and HTTP validation with #Cloudflare

    - Installation and configuration of
    #csi-driver-smb which adds support for integrating your external SMB storage to the Kubernetes cluster

    Besides these, there are also some other
    helper scripts to make certain related tasks easy such as a script to set a unique static IP address and hostname, and another to toggle #SELinux enforcement to on or off - should you need to turn it off (temporarily).

    If you already have an existing RKE2 cluster, there's a step-by-step guide on how you could use it to easily configure and join additional nodes to your cluster if you're planning on expanding.

    Orked currently expects and supports
    #RockyLinux 8+ (should also support any other #RHEL distros such as #AlmaLinux), but I am planning to improve the project over time by adding more #Linux distros, #IPv6 support, and possibly even #K3s for a more lightweight #RaspberryPi cluster for example.

    I've used this exact setup to deploy and manage vital services to hundreds of unique clients/organisations that I've become
    obsessed with sharing it to everyone and making it easier to get started. If this is something that interests you, feel free to check it out!

    If you're wondering what to deploy on a Kubernetes cluster - feel free to also check out my
    #mika helm chart repo 🥳

    🔗 https://github.com/irfanhakim-as/orked

    🔗 https://github.com/irfanhakim-as/charts

  25. I've just merged a huge PR to my #Orked (O-tomated RKE Distribution - GREAT NAME I KNOW) that makes it easier than ever for anyone to set up a production-ready #RKE2 #Kubernetes cluster in their #homelab.

    With this collection of scripts, all you need to do is just provision the nodes required, including a login/management node, and run the scripts right from the login node to configure all of the other nodes to make up the cluster. This setup includes:

    - Configuring the Login node with any required or essential dependencies (such as
    #Helm, #Docker, #k9s, #kubens, #kubectx, etc.)

    - Setup passwordless
    #SSH access from the Login node to the rest of the Kubernetes nodes

    - Update the
    hosts file for strictly necessary name resolution on the Login node and between the Kubernetes nodes

    - Necessary, best practice configurations for all of the Kubernetes nodes including networking configuration, disabling unnecessary services, disabling swap, loading required modules, etc.

    - Installation and configuration of RKE2 on all the Kubernetes nodes and joining them together as a cluster

    - Installation and configuration of
    #Longhorn storage, including formatting/configuring their virtual disks on the Worker nodes

    - Deployment and configuration of
    #MetalLB as the cluster's load-balancer

    - Deployment and configuration of
    #Ingress #NGINX as the ingress controller and reverse proxy for the cluster - this helps manage external access to the services in the cluster

    - Setup and configuration of
    #cert-manager to obtain and renew #LetsEncrypt certs automatically - supports both #DNS and HTTP validation with #Cloudflare

    - Installation and configuration of
    #csi-driver-smb which adds support for integrating your external SMB storage to the Kubernetes cluster

    Besides these, there are also some other
    helper scripts to make certain related tasks easy such as a script to set a unique static IP address and hostname, and another to toggle #SELinux enforcement to on or off - should you need to turn it off (temporarily).

    If you already have an existing RKE2 cluster, there's a step-by-step guide on how you could use it to easily configure and join additional nodes to your cluster if you're planning on expanding.

    Orked currently expects and supports
    #RockyLinux 8+ (should also support any other #RHEL distros such as #AlmaLinux), but I am planning to improve the project over time by adding more #Linux distros, #IPv6 support, and possibly even #K3s for a more lightweight #RaspberryPi cluster for example.

    I've used this exact setup to deploy and manage vital services to hundreds of unique clients/organisations that I've become
    obsessed with sharing it to everyone and making it easier to get started. If this is something that interests you, feel free to check it out!

    If you're wondering what to deploy on a Kubernetes cluster - feel free to also check out my
    #mika helm chart repo 🥳

    🔗 https://github.com/irfanhakim-as/orked

    🔗 https://github.com/irfanhakim-as/charts

  26. I've just merged a huge PR to my #Orked (O-tomated RKE Distribution - GREAT NAME I KNOW) that makes it easier than ever for anyone to set up a production-ready #RKE2 #Kubernetes cluster in their #homelab.

    With this collection of scripts, all you need to do is just provision the nodes required, including a login/management node, and run the scripts right from the login node to configure all of the other nodes to make up the cluster. This setup includes:

    - Configuring the Login node with any required or essential dependencies (such as
    #Helm, #Docker, #k9s, #kubens, #kubectx, etc.)

    - Setup passwordless
    #SSH access from the Login node to the rest of the Kubernetes nodes

    - Update the
    hosts file for strictly necessary name resolution on the Login node and between the Kubernetes nodes

    - Necessary, best practice configurations for all of the Kubernetes nodes including networking configuration, disabling unnecessary services, disabling swap, loading required modules, etc.

    - Installation and configuration of RKE2 on all the Kubernetes nodes and joining them together as a cluster

    - Installation and configuration of
    #Longhorn storage, including formatting/configuring their virtual disks on the Worker nodes

    - Deployment and configuration of
    #MetalLB as the cluster's load-balancer

    - Deployment and configuration of
    #Ingress #NGINX as the ingress controller and reverse proxy for the cluster - this helps manage external access to the services in the cluster

    - Setup and configuration of
    #cert-manager to obtain and renew #LetsEncrypt certs automatically - supports both #DNS and HTTP validation with #Cloudflare

    - Installation and configuration of
    #csi-driver-smb which adds support for integrating your external SMB storage to the Kubernetes cluster

    Besides these, there are also some other
    helper scripts to make certain related tasks easy such as a script to set a unique static IP address and hostname, and another to toggle #SELinux enforcement to on or off - should you need to turn it off (temporarily).

    If you already have an existing RKE2 cluster, there's a step-by-step guide on how you could use it to easily configure and join additional nodes to your cluster if you're planning on expanding.

    Orked currently expects and supports
    #RockyLinux 8+ (should also support any other #RHEL distros such as #AlmaLinux), but I am planning to improve the project over time by adding more #Linux distros, #IPv6 support, and possibly even #K3s for a more lightweight #RaspberryPi cluster for example.

    I've used this exact setup to deploy and manage vital services to hundreds of unique clients/organisations that I've become
    obsessed with sharing it to everyone and making it easier to get started. If this is something that interests you, feel free to check it out!

    If you're wondering what to deploy on a Kubernetes cluster - feel free to also check out my
    #mika helm chart repo 🥳

    🔗 https://github.com/irfanhakim-as/orked

    🔗 https://github.com/irfanhakim-as/charts

  27. A new TUI is being cooked! 👨‍🍳

    🦆 **ducker**: A terminal app for managing Docker containers.

    🦀 Written in Rust & built with @ratatui_rs

    ⭐ GitHub: github.com/robertpsoane/ducker

  28. How do you pronounce "k9s" as in, the Kubernetes management UI?
    I call it [kuber-nineties], because its wonderfully old-school text UI reminds me of nineties DOS ☺️ That, and [kubernetes] is typically abbreviated k8s.
    But, I don't know what for example the k9s developers call it.

  29. If you have the misfortune of managing k8s clusters, you are probably familiar with k9s. I wanted to be able to use k9s remotely via web browser, so I combined it with ttyd into a single docker container: github.com/LordMathis/k9s-web

    #k9s #kubernetes #k8s #ttyd

  30. I've just published my next YouTube video! (sorry, it's been a while!). This one is on the amazing #k9s #kubernetes UI! youtu.be/A4273rg4tDw #k8s

  31. Okay, I think I found a decent solution for my future 2-node #RaspberryPi #HomeLab cluster:

    - install #K3s using @technotim playbooks: technotim.live/posts/k3s-etcd-
    - monitor the cluster using @carlosedp stack: github.com/carlosedp/cluster-m
    - webUI using the standard #Kubernetes dashboard: kubernetes.io/docs/tasks/acces
    - CLI using #K9s: k9scli.io/

    Net-result: 20% memory usage vs 50% with #Rancher.

    Yep, I think that should make it a nice start. Let's see how it goes. 😉

  32. TIL about , desktop client for . I still prefer , but it's worth giving a try | github.com/MuhammedKalkan/Open

  33. Donate to at least 10 FOSS projects I used often, at least $100 totally in 2023(and hopefully every year)

    -
    -
    -
    -
    -
    -
    -
    -
    - <TBC>
    - <TBC>

  34. Here is a dev tip. If you have to do anything with or around Kubernetes, k9s will make your life so much easier: k9scli.io/

    k9s is an auxiliary UI around kubectl. You simply turn it on in a terminal and it will live there. k9s gives an immediate feedback around the status of pods and nodes, and saves you from typing 80% of the boilerplate-y kubectl commands.

    ---
    #devtip #kubernetes #k8s #kubectl #k9s

  35. @ikkeT while #yq is super useful, especially in scripts, I have found #k9s to be super for exploring cluster and doing small edits.