github/awesome-kubernetes
1
0
Fork 0
mirror of https://github.com/nubenetes/awesome-kubernetes.git synced 2026-05-23 01:24:08 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: update docs/about.md [20260518-1212]

Browse Source
This commit is contained in:
github-actions[bot]
2026-05-18 12:15:04 +00:00
committed by GitHub
parent 327ef7200b
commit ab0bdd8a54
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/about.md
View File

@@ -20,7 +20,7 @@ In a service driven IT sector (with calculated ambiguities and many hidden inter
A tech stack is not relevant compared to the way technology is managed. You could have the best tool and run into trouble by taking the risk of applying an unsupported or not recommended[^1] approach.
[^1]:For example: [OpenShift deployment using the UPI method instead of IPI](https://keithtenzer.com/openshift/openshift-4-aws-ipi-installation-getting-started-guide//#:~:text=OpenShift%20offers%20two%20possible%20deployment%20methods%3A%20IPI%20(as%20mentioned)%20and%20UPI%20(User%20Provisioned%20Infrastructure).%20The%20difference%20is%20the%20degree%20of%20automation%20and%20customization.%20IPI%20will%20not%20only%20deploy%20OpenShift%20but%20also%20all%20infrastructure%20components%20and%20configurations.) because of lack of permissions as an excuse.
[^1]:For example: [OpenShift deployment using the UPI method instead of IPI](https://keithtenzer.com/openshift/openshift-4-aws-ipi-installation-getting-started-guide///#:~:text=OpenShift%20offers%20two%20possible%20deployment%20methods%3A%20IPI%20(as%20mentioned)%20and%20UPI%20(User%20Provisioned%20Infrastructure).%20The%20difference%20is%20the%20degree%20of%20automation%20and%20customization.%20IPI%20will%20not%20only%20deploy%20OpenShift%20but%20also%20all%20infrastructure%20components%20and%20configurations.) because of lack of permissions as an excuse.
**DevOps principles: People, processes, technology**
@@ -31,7 +31,7 @@ A tech stack is not relevant compared to the way technology is managed. You coul
| __DevOps__ | Automation and frequent deployments | CI/CD pipeline | Supply chain management, Cloud Configuration as Code, etc. | Less strict and more open | Less focus on correctness |
| __GitOps__ | ==Correctness; doing DevOps correctly== | Git | Kubernetes, Controller (e.g., Operator), separate CI/CD pipelines, Infrastructure as a Code, etc. | ==Stricter and less open== | ==Designed with correctness== |
>[The SRE Experience Is Changing with Cloud Native:](https://thenewstack.io/how-the-sre-experience-is-changing-with-cloud-native//)
>[The SRE Experience Is Changing with Cloud Native:](https://thenewstack.io/how-the-sre-experience-is-changing-with-cloud-native///)
>
>- From Firefighting to Prevention for SREs.
>- Empower Developers with Self-Service.
@@ -79,11 +79,11 @@ Instead of [reinventing the wheel](https://devdriven.by/promotion/) by rewriting
Does saying this publicly imply being blacklisted and losing professional opportunities? What kind of society do we live in?
Tips: ask the hiring manager what experience they have with Cloud Automation, Cloud Managed Services and K8s in Production, if they deploy OpenShift via IPI[^1] or UPI, whether they are familiar with [Gitops](https://thenewstack.io/kubernetes-at-scale-without-gitops-is-a-bad-idea//) as the correct way of doing DevOps, if they work with modern, easy-to-use automation tools ([terraform](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs), [ansible modules](https://docs.ansible.com/projects/ansible/latest/collections/kubernetes/core/k8s_module.html) with YAML/[Jinja templates](https://github.com/pallets/jinja/), argocd, helm, an automation server[^3] to run pipelines, declarative code in Jenkins[^4] Pipelines or in DevOps Azure Pipelines, [IaC boilerplates](https://nubenetes.com/terraform/) instead of [k8s vanilla](https://www.digitalocean.com/blog/vanilla-kubernetes-vs-managed-kubernetes), etc) or they are not practical and prefer to develop their own ad-hoc tools with millions of lines of code that need maintenance (by who?). If any doubt, ask them to show you their pipelines and custom solutions, how long it takes them to deploy and setup their k8s infra on day 1 & day 2 (pets vs cattle service model), how long it takes them to deploy a single app and if the process is fully automated or not, what monitoring solutions they have, if security and Role-based Access Control (RBAC) are implemented in their k8s clusters, whether changes and PoCs are tested first in ephemeral and isolated K8s/Cloud infra test environments with IaC & CI/CD pipelines, if solutions can be discussed within the team, etc.
Tips: ask the hiring manager what experience they have with Cloud Automation, Cloud Managed Services and K8s in Production, if they deploy OpenShift via IPI[^1] or UPI, whether they are familiar with [Gitops](https://thenewstack.io/kubernetes-at-scale-without-gitops-is-a-bad-idea///) as the correct way of doing DevOps, if they work with modern, easy-to-use automation tools ([terraform](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs), [ansible modules](https://docs.ansible.com/projects/ansible/latest/collections/kubernetes/core/k8s_module.html) with YAML/[Jinja templates](https://github.com/pallets/jinja/), argocd, helm, an automation server[^3] to run pipelines, declarative code in Jenkins[^4] Pipelines or in DevOps Azure Pipelines, [IaC boilerplates](https://nubenetes.com/terraform/) instead of [k8s vanilla](https://www.digitalocean.com/blog/vanilla-kubernetes-vs-managed-kubernetes), etc) or they are not practical and prefer to develop their own ad-hoc tools with millions of lines of code that need maintenance (by who?). If any doubt, ask them to show you their pipelines and custom solutions, how long it takes them to deploy and setup their k8s infra on day 1 & day 2 (pets vs cattle service model), how long it takes them to deploy a single app and if the process is fully automated or not, what monitoring solutions they have, if security and Role-based Access Control (RBAC) are implemented in their k8s clusters, whether changes and PoCs are tested first in ephemeral and isolated K8s/Cloud infra test environments with IaC & CI/CD pipelines, if solutions can be discussed within the team, etc.
[^3]: Jenkins/CloudBees, Ansible Tower/AWX, Foreman, Rundeck, Azure DevOps, GitLab CI, etc.
[^4]: Automation with [Jenkins Configuration as Code](https://www.jenkins.io/projects/jcasc//) replaces what was previously done via [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli//) and [jenkins remote REST API](https://www.jenkins.io/doc/book/using/remote-access-api//) calls (requiring backend development with tools like [swagger](https://swagger.io/) and API Testing tools like [postman](https://www.postman.com/)). Similar scenario applies to other technologies.
[^4]: Automation with [Jenkins Configuration as Code](https://www.jenkins.io/projects/jcasc///) replaces what was previously done via [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli///) and [jenkins remote REST API](https://www.jenkins.io/doc/book/using/remote-access-api//) calls (requiring backend development with tools like [swagger](https://swagger.io/) and API Testing tools like [postman](https://www.postman.com/)). Similar scenario applies to other technologies.
> [*"The absolutely difficult thing is reaching volume production without going bankrupt, that is the actual hard thing"*](https://www.youtube.com/watch?v=cdZZpaB2kDM&t=2025s) Elon Musk