#k9s — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #k9s, aggregated by home.social.
-
Топ-8 опенсорс‑инструментов, которые необходимы разработчику в кубере
Open source инструменты удобны для разработчика: настраиваешь их под себя и не зависишь от чужих правил, ценников и внезапных ограничений. Плюс вокруг них обычно есть живая документация и комьюнити — проблемы и решения редко остаются «в вакууме». Собрали с командой R&D список инструментов, которыми сами пользуемся ежедневно. В подборке — опенсорсные инструменты для разных ситуаций: от работы с Kubernetes и контейнерными реестрами до тестирования API, проверки чужих репозиториев и runtime‑наблюдения за безопасностью контейнеров.
https://habr.com/ru/companies/pt/articles/1009520/
#cybersecurity #backend #runtime #code_review #freelens #k9s #skopeo #bruno #zed
-
Топ-8 опенсорс‑инструментов, которые необходимы разработчику в кубере
Open source инструменты удобны для разработчика: настраиваешь их под себя и не зависишь от чужих правил, ценников и внезапных ограничений. Плюс вокруг них обычно есть живая документация и комьюнити — проблемы и решения редко остаются «в вакууме». Собрали с командой R&D список инструментов, которыми сами пользуемся ежедневно. В подборке — опенсорсные инструменты для разных ситуаций: от работы с Kubernetes и контейнерными реестрами до тестирования API, проверки чужих репозиториев и runtime‑наблюдения за безопасностью контейнеров.
https://habr.com/ru/companies/pt/articles/1009520/
#cybersecurity #backend #runtime #code_review #freelens #k9s #skopeo #bruno #zed
-
Топ-8 опенсорс‑инструментов, которые необходимы разработчику в кубере
Open source инструменты удобны для разработчика: настраиваешь их под себя и не зависишь от чужих правил, ценников и внезапных ограничений. Плюс вокруг них обычно есть живая документация и комьюнити — проблемы и решения редко остаются «в вакууме». Собрали с командой R&D список инструментов, которыми сами пользуемся ежедневно. В подборке — опенсорсные инструменты для разных ситуаций: от работы с Kubernetes и контейнерными реестрами до тестирования API, проверки чужих репозиториев и runtime‑наблюдения за безопасностью контейнеров.
https://habr.com/ru/companies/pt/articles/1009520/
#cybersecurity #backend #runtime #code_review #freelens #k9s #skopeo #bruno #zed
-
Топ-8 опенсорс‑инструментов, которые необходимы разработчику в кубере
Open source инструменты удобны для разработчика: настраиваешь их под себя и не зависишь от чужих правил, ценников и внезапных ограничений. Плюс вокруг них обычно есть живая документация и комьюнити — проблемы и решения редко остаются «в вакууме». Собрали с командой R&D список инструментов, которыми сами пользуемся ежедневно. В подборке — опенсорсные инструменты для разных ситуаций: от работы с Kubernetes и контейнерными реестрами до тестирования API, проверки чужих репозиториев и runtime‑наблюдения за безопасностью контейнеров.
https://habr.com/ru/companies/pt/articles/1009520/
#cybersecurity #backend #runtime #code_review #freelens #k9s #skopeo #bruno #zed
-
@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.
-
#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: https://blog.bitfoo.de/posts/k9s-plugins/
#DevOps #k8s #Kubernetes #SRE #CloudNative #Linux #OpenSource #Containers #Homelab #PlatformEngineering #Docker
-
Vice President JD Vance departs Naples after private fundraiser
Vice President JD Vance visited Naples for a high-profile fundraiser on Wednesday.Law enforcement surrounded the perimeter …
#UnitedStates #US #USA #colliercountydeputy #count #Entertainment #grass #gulfcoastnews #high-profilefundraiser #JamesDavidVance #jdvance #k9s #latenews #Naples #privatefundraiser #secretserviceagent #Sport #vance #vicepresident #vicepresidentjdvance #VP #Weather #wednesday
https://www.europesays.com/2738163/ -
🖥️ #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🧵 👇
-
Wow, look what cool thing I found – K9s (https://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
-
The #OverUnder series is back. This week, @KevinGimbel will give his opinion on:
-#Sony cameras
-#RaspberryPi
- B&W #photography
-#k9s
-#Macchiato #coffeeThis is 89/100 post for the #100DaysToOffload challenge.
https://lazybea.rs/ovr-032 -
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. Немного танцев с бубном
На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т.д. Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую-то ветку с разрабатываемой фичей или исправлением бага в ветку, которая “привязана” к окружению и дальше наш код деплоится в кластер. Думаю, для многих - это уже стандартная история. Давайте представим, что нужно сделать задачу, относящуюся к какому-нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на “боевые”. Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы “ковыряем” и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:
https://habr.com/ru/articles/926556/
#kubernetes #minikube #telepresence #k9s #микросервисы #разработка #kubectl
-
Локальная разработка с Kubernetes. Немного танцев с бубном
На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т.д. Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую-то ветку с разрабатываемой фичей или исправлением бага в ветку, которая “привязана” к окружению и дальше наш код деплоится в кластер. Думаю, для многих - это уже стандартная история. Давайте представим, что нужно сделать задачу, относящуюся к какому-нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на “боевые”. Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы “ковыряем” и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:
https://habr.com/ru/articles/926556/
#kubernetes #minikube #telepresence #k9s #микросервисы #разработка #kubectl
-
Локальная разработка с Kubernetes. Немного танцев с бубном
На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т.д. Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую-то ветку с разрабатываемой фичей или исправлением бага в ветку, которая “привязана” к окружению и дальше наш код деплоится в кластер. Думаю, для многих - это уже стандартная история. Давайте представим, что нужно сделать задачу, относящуюся к какому-нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на “боевые”. Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы “ковыряем” и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:
https://habr.com/ru/articles/926556/
#kubernetes #minikube #telepresence #k9s #микросервисы #разработка #kubectl
-
Локальная разработка с Kubernetes. Немного танцев с бубном
На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т.д. Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую-то ветку с разрабатываемой фичей или исправлением бага в ветку, которая “привязана” к окружению и дальше наш код деплоится в кластер. Думаю, для многих - это уже стандартная история. Давайте представим, что нужно сделать задачу, относящуюся к какому-нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на “боевые”. Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы “ковыряем” и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:
https://habr.com/ru/articles/926556/
#kubernetes #minikube #telepresence #k9s #микросервисы #разработка #kubectl
-
Das Juni-Treffen der #Python #Usergroup #Graz steht an.
Diesmal gibt es einen Vortrag (auf Englisch) von #Nicoo zum Thema:
"Modern #operations in python with #kubernetes "
- 3. Juni 2025 ab 19:00 Uhr
- im #Realraum#ops #kubectl #k9s #steiermark #styria
https://events.graz.social/events/8ffb9999-ddf6-49df-841b-9292d1474ad9
-
Das Juni-Treffen der #Python #Usergroup #Graz steht an.
Diesmal gibt es einen Vortrag (auf Englisch) von #Nicoo zum Thema:
"Modern #operations in python with #kubernetes "
- 3. Juni 2025 ab 19:00 Uhr
- im #Realraum#ops #kubectl #k9s #steiermark #styria
https://events.graz.social/events/8ffb9999-ddf6-49df-841b-9292d1474ad9
-
Das Juni-Treffen der #Python #Usergroup #Graz steht an.
Diesmal gibt es einen Vortrag (auf Englisch) von #Nicoo zum Thema:
"Modern #operations in python with #kubernetes "
- 3. Juni 2025 ab 19:00 Uhr
- im #Realraum#ops #kubectl #k9s #steiermark #styria
https://events.graz.social/events/8ffb9999-ddf6-49df-841b-9292d1474ad9
-
Das Juni-Treffen der #Python #Usergroup #Graz steht an.
Diesmal gibt es einen Vortrag (auf Englisch) von #Nicoo zum Thema:
"Modern #operations in python with #kubernetes "
- 3. Juni 2025 ab 19:00 Uhr
- im #Realraum#ops #kubectl #k9s #steiermark #styria
https://events.graz.social/events/8ffb9999-ddf6-49df-841b-9292d1474ad9
-
Das Juni-Treffen der #Python #Usergroup #Graz steht an.
Diesmal gibt es einen Vortrag (auf Englisch) von #Nicoo zum Thema:
"Modern #operations in python with #kubernetes "
- 3. Juni 2025 ab 19:00 Uhr
- im #Realraum#ops #kubectl #k9s #steiermark #styria
https://events.graz.social/events/8ffb9999-ddf6-49df-841b-9292d1474ad9
-
I'm using k9s to view my Kubernetes objects.
One can use K9S_FEATURE_GATE_NODE_SHELL=true| to enable node shell.
Link: https://k9scli.io/topics/config/
cc: @bycx
-
I'm using k9s to view my Kubernetes objects.
One can use K9S_FEATURE_GATE_NODE_SHELL=true| to enable node shell.
Link: https://k9scli.io/topics/config/
cc: @bycx
-
I'm using k9s to view my Kubernetes objects.
One can use K9S_FEATURE_GATE_NODE_SHELL=true| to enable node shell.
Link: https://k9scli.io/topics/config/
cc: @bycx
-
I'm using k9s to view my Kubernetes objects.
One can use K9S_FEATURE_GATE_NODE_SHELL=true| to enable node shell.
Link: https://k9scli.io/topics/config/
cc: @bycx
-
I'm using k9s to view my Kubernetes objects.
One can use K9S_FEATURE_GATE_NODE_SHELL=true| to enable node shell.
Link: https://k9scli.io/topics/config/
cc: @bycx
-
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
-
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.
[…]
-
Does YOUR project need #Kubernetes?
-
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 eitherPending,Unknownor 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 formigration. #Homelab folks please feel free sending some suggestions my way, that is as dummy-friendly as possible :))
RE: https://sakurajima.social/notes/a2e9fm36yg -
https://www.docker.com/blog/creating-kubernetes-extensions-in-docker-desktop/ - creating the #k9s #Docker Desktop extension. Nice walk-through James Spurin.
-
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 thehostsfile 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 -
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 thehostsfile 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 -
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 thehostsfile 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 -
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 thehostsfile 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 -
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 thehostsfile 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 -
A new TUI is being cooked! 👨🍳
🦆 **ducker**: A terminal app for managing Docker containers.
🦀 Written in Rust & built with @ratatui_rs
⭐ GitHub: https://github.com/robertpsoane/ducker
#rustlang #tui #ratatui #docker #containers #k8s #k9s #tooling #terminal
-
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. -
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: https://github.com/LordMathis/k9s-web
-
I've just published my next YouTube video! (sorry, it's been a while!). This one is on the amazing #k9s #kubernetes UI! https://youtu.be/A4273rg4tDw #k8s
-
Okay, I think I found a decent solution for my future 2-node #RaspberryPi #HomeLab cluster:
- install #K3s using @technotim playbooks: https://technotim.live/posts/k3s-etcd-ansible/
- monitor the cluster using @carlosedp stack: https://github.com/carlosedp/cluster-monitoring
- webUI using the standard #Kubernetes dashboard: https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/
- CLI using #K9s: https://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. 😉
-
TIL about #OpenLens, desktop client for #Kubernetes. I still prefer #k9s, but it's worth giving a try | https://github.com/MuhammedKalkan/OpenLens
-
Donate to at least 10 FOSS projects I used often, at least $100 totally in 2023(and hopefully every year)
- #helix
- #homeassistant
- #memos
- #pocketbase
- #wezterm
- #k9s
- #tridactyl
- #ripgrep
- <TBC>
- <TBC> -
Local #Development Techniques with #Kubernetes. It's a #NoSlides demo of #Minikube, #Portainer, #Skooner, #Dive, #k9s, and many more. Join us at #Geekle #DevOps Global Summit at https://events.geekle.us/devops23/ and grab the list of tools at https://gist.github.com/robrich/5abd6c1261eae55476db2a15d1c2180a.
-
Here is a dev tip. If you have to do anything with or around Kubernetes, k9s will make your life so much easier: https://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.