Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
keda
KEDA is a Kubernetes-based Event Driven Autoscaling component. It provides event driven scale for any container running in Kubernetes
-
karpenter-provider-aws
Karpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.
-
-
-
devspace
DevSpace - The Fastest Developer Tool for Kubernetes ⚡ Automate your deployment workflow with DevSpace and develop software directly inside Kubernetes.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Build: Workloads need to be containerized. That leads to long build times, especially if there is no caching possible/enabled for the build. A local build might be just a hot reload, but these can take many minutes with the container build step included. Please use podman, kaniko, or similar over docker for builds.
Debug - difference between local and dev environments: Replicating bugs from remote environments to local is tough. Tools like devspace and telepresence help. The former enables a quick build loop between the local and the remote k8s environment and can be massively helpful in reducing development time. The latter is a lot more magic, directing remote traffic to your local laptop, but is more complex to work with.
Cluster - Nodes: This is the number of EC2 instances required to satisfy the application requirements. The cluster-autoscaler or karpenter projects are great for this.
Setup policy around what resource requirements can be requested by an app per environment. OPA and gatekeeper or kyverno can help. Setup access control for who can create or modify apps.
Setup policy around what resource requirements can be requested by an app per environment. OPA and gatekeeper or kyverno can help. Setup access control for who can create or modify apps.
Deploy: The deployment experience itself is super neat. The complexity of defining the deployment, which is usually a one-time heavy lift followed by minor modifications for maintenance, is pretty high and requires k8s-specific knowledge. Some tools help with the automatic generation of k8s manifests for easy use, like skaffold, devspace, dokku, and more.
Build: Workloads need to be containerized. That leads to long build times, especially if there is no caching possible/enabled for the build. A local build might be just a hot reload, but these can take many minutes with the container build step included. Please use podman, kaniko, or similar over docker for builds.
Setup multiple clusters across regions and connect them to operate as a single entity as far as apps are concerned. This needs a service mesh like linkerd.
Setup policy around what resource requirements can be requested by an app per environment. OPA and gatekeeper or kyverno can help. Setup access control for who can create or modify apps.
Application - Horizontal Scaling: Creating more instances of the application to keep up with the load. Keda is the tool for this.
Cluster - Nodes: This is the number of EC2 instances required to satisfy the application requirements. The cluster-autoscaler or karpenter projects are great for this.
Debug - logging into remote: While devspace, telepresence, and skaffold are nice for remote dev, sometimes the easiest thing to do is to login to the remote container for debugging. You definitely want to use a Kubernetes dashboard - k8s lens, or k9s cli. Along with this, you can use kubectl exec to open up a shell in the container or use ephemeral containers to attach to a running pod introduced in k8s v1.23. The latter is the preferred method in dev environments. Neither of these should be done in prod environments.
Debug - logging into remote: While devspace, telepresence, and skaffold are nice for remote dev, sometimes the easiest thing to do is to login to the remote container for debugging. You definitely want to use a Kubernetes dashboard - k8s lens, or k9s cli. Along with this, you can use kubectl exec to open up a shell in the container or use ephemeral containers to attach to a running pod introduced in k8s v1.23. The latter is the preferred method in dev environments. Neither of these should be done in prod environments.
Deploy: The deployment experience itself is super neat. The complexity of defining the deployment, which is usually a one-time heavy lift followed by minor modifications for maintenance, is pretty high and requires k8s-specific knowledge. Some tools help with the automatic generation of k8s manifests for easy use, like skaffold, devspace, dokku, and more.
Debug - difference between local and dev environments: Replicating bugs from remote environments to local is tough. Tools like devspace and telepresence help. The former enables a quick build loop between the local and the remote k8s environment and can be massively helpful in reducing development time. The latter is a lot more magic, directing remote traffic to your local laptop, but is more complex to work with.