kube-monkey
flux2
kube-monkey | flux2 | |
---|---|---|
9 | 83 | |
2,920 | 5,943 | |
- | 1.5% | |
3.4 | 9.2 | |
13 days ago | 3 days ago | |
Go | Go | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
kube-monkey
-
Does your company have a Change Advisory Board (CAB)?
Not in the typical sense, but we have plenty of standard practices and cross-team checkpoints to limit risk. By the time we're deploying changes to production, the work has had a card created, assigned points (which necessarily involves discussing scope and risk), architected (as a group), code peer reviewed, hit unit tests (automated), integration tests (automated), functional tests (automated), smoke tested (automated) end-to-end tests (a few automated, but mostly manual by QA), acceptance tested (by QA and business), resilience tests (chaos engineering with kube-monkey), been deployed to at least 3 environments (with the same exact same artifacts, just with config changes), and monitored for failures (pod restarts, log anomalies, etc -- all automated). Deploy to production is well communicated, and ANY team can request a halt to the deploy if they have concerns.
- Kube-monkey: an implementation of Netflix's Chaos Monkey for Kubernetes clusters
-
What happens when a service fails in your infra, or in other words, do you practice chaos engineering?
Part of being a cloud native company means designing services for failure. What happens, for example, if the payment service/pod goes down? Do the rest of your services continue operating normally? One thing tools like kube-monkey does is automatically kill pods for you on a certain date at a certain time in order to plan for failure events. Just wondering if anyone has dove into the deep end with this type of tooling and really just gone all out, besides Netflix?
-
Chaos Mesh for chaos engineering in Kubernetes
Chaos Mesh is a popular solution (about 5k GitHub stars), but — obviously — not the only one. E.g., Litmus is a powerful platform to test many things, and kube-monkey might be a good option for more basic stuff.
-
How many of you actually test your infrastructure code? For those that do, what benefits did you discover that testing brings to your code base?
Exactly the kind of thing I love to see! Sounds like a great use case for a tool like kube-monkey as well.
- GitHub - asobti/kube-monkey: An implementation of Netflix's Chaos Monkey for Kubernetes clusters
- kube-monkey: An implementation of Netflix's Chaos Monkey for Kubernetes clusters
- 27 open-source tools that can make your Kubernetes workflow easier 🚀🥳
-
Awesome Kubernetes Resources
Kube Monkey
flux2
-
Self-service infrastructure as code
Given the team had already adopted GitOps and were familiar with deployments powered by Helm Releases and Flux, we wanted to move the provisioning of the infrastructure to be part of the same process of creating the service and its continuous deployment.
-
Weaveworks Is Shuting Down
Your GitHub action can trigger a helm chart, or series thereof, or other infra tools. Declarative specifications, triggered procedurally with the context of the branch’s latest build. We use this pattern quite extensively for preview app workflows.
As of a year ago this is possible in a fully declarative way with Flux 2, but there’s a lot more moving parts and security footguns - and the idea that the maintenance of this project has lost one of its primary sponsors is worrying at best.
https://github.com/fluxcd/flux2/discussions/831
https://blog.kluctl.io/introducing-the-template-controller-a...
-
10 Ways for Kubernetes Declarative Configuration Management
FluxCD - FluxCD is another popular GitOps tool that allows developers to use a Git repository as the sole source of configuration. Flux automatically ensures that the state of the Kubernetes cluster is synchronized with the configuration in the Git repository. It supports automatic updates, meaning Flux can monitor Docker image repositories for new images and push updates to the cluster.
-
SmartCash Project - GitOps with FluxCD
#!/bin/bash aws eks update-kubeconfig --name $CLUSTER_NAME --region $AWS_REGION flux_installed=$(kubectl api-resources | grep flux) if [ -z "$flux_installed" ]; then echo "flux is not installed" curl -s https://fluxcd.io/install.sh | sudo bash flux bootstrap github \ --owner=$GH_USER_NAME \ --repository=$FLUX_REPO_NAME \ --path="clusters/$ENVIRONMENT/$CLUSTER_NAME/bootstrap" \ --branch=main \ --personal else echo "flux is installed" fi
-
Best Kubernetes DevOps Tools: A Comprehensive Guide
Flux CD enables continuous deployment to Kubernetes through GitOps by syncing Git repositories with Kubernetes clusters. Flux CD enables GitOps for Kubernetes through source control integration. It manages Kubernetes manifests as code and syncs git repo changes to clusters. Flux automates checks, deployments, and updates within clusters.
- Flux – a tool for keeping K8s clusters in sync with sources of configuration
-
Git going with GitOps on AKS: A Step-by-Step Guide using FluxCD AKS Extension
FluxCD is a GitOps tool developed by Weaveworks that allows you to implement continuous and progressive delivery of your applications on Kubernetes. It is a CNCF graduated project that offers a set of controllers to monitor Git repositories and reconciles the cluster's actual state with the desired state defined by manifests committed in the repo.
-
Ultimate EKS Baseline Cluster: Part 1 - Provision EKS
From here, we can explore other developments and tutorials on Kubernetes, such as o11y or observability (PLG, ELK, ELF, TICK, Jaeger, Pyroscope), service mesh (Linkerd, Istio, NSM, Consul Connect, Cillium), and progressive delivery (ArgoCD, FluxCD, Spinnaker).
-
Reducing Cloud Costs on Kubernetes Dev Envs
Instead, we will create a single long-lived cluster, and deploy our application in different namespaces. There are a bunch of ways to do that - see ArgoCD, Flux, custom internal tooling, or other solutions (we use our own product). That way, we:
-
What is the proper, kubernetes native way of working with multiple clusters for DR, HA?
One is to make sure configurations in both clusters is same. And for that there are many tools like fluxcd or projectsveltos
What are some alternatives?
chaoskube - chaoskube periodically kills random pods in your Kubernetes cluster.
helmfile - Deploy Kubernetes Helm Charts
istio - Connect, secure, control, and observe services.
argo-cd - Declarative Continuous Deployment for Kubernetes
kube-bench - Checks whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark
spinnaker - Spinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence.
skaffold - Easy and Repeatable Kubernetes Development
terraform-provider-flux - Terraform and OpenTofu provider for bootstrapping Flux
kube-burner - Kubernetes performance and scale test orchestration framework written in golang
quay - Build, Store, and Distribute your Applications and Containers
werf - A solution for implementing efficient and consistent software delivery to Kubernetes facilitating best practices.