DevOps

Part 1 of a series on managing Kubernetes configuration at scale. Upcoming: comparing CUE and Helm for different use cases, and integrating CUE into CI/CD pipelines and GitOps workflows. I have spent the past four years as a DevOps engineer reading, using, and writing Helm charts — from small internal deployment wrappers to large, multi-team platform charts. I have read through the internals of charts for Istio, CockroachDB, ArgoCD, cert-manager, and Vault, and written enough _helpers.tpl macros and validations to last a lifetime. ...

Introduction During developing services, there are some cases we need to send HTTPS requests to external services. When using Istio, requests based on the hosts that are not registered in Service registry are essentially recognized as a Cluster named Passthrough, which just operates solely as a TCP proxy. That is, Envoy simply forwards those TCP packets without performing any additional functionality on them. In this case, for requests based on HTTPS which operates at the L7 layer, Istio is only able to record TCP-level metrics, resulting in limited information available for TCP metrics. ...

Introduction Connections can be reset abnormarly with terminating pods when you manage istio as a service mesh solution on kubernetes. There are a number of cases terminating pods: manually executing kubectl delete commands, rolling updates and scaling in them. So, why are connections reset? There can be many other reasons but I think it is the most probable terminating of istio-proxy sidecars earlier than terminating of application containers. Prior to istio v1.12, some people used to add a preStop configuration in order to clarify for istio-proxy containers to terminates after all the active connections completes well. ...