Welcome to series of write-ups on my learnings, findings on distributed tracing… What is Distributed Tracing? Distributed tracing is the capability to track and observe service requests as the flow through distributed systems by collecting data as the requests go from one service to another and helps you to perform the root cause analysis for a specifc request. A distributed trace is a directed acyclic graph of spans, where the edges of these spans are defined in parent, child relationship.
Let’s first start with what is CNCF Cloud Native Computing Foundation is a collection of technologies and practices that automate the deployment and management of highly decoupled and resilient application workloads across elastic infrastructures using a uniform abstraction of computing resources. - Vladimir Vivien CNCF mentorships programs Google Summer of Code (GSoC) Google Season of Docs (GSoD) LFX Mentorship (formerly community bridge) Outreachy Understand the CNCF landscape
As Kubernetes clusters runs different resources at desired scale. We need to have full control over the cluster with all lifecycle of events and audits which helps us to trace out the source. Also, it would be great to get notified when something abnormal happens in the cluster. Now let’s look at the details we need from api-server when an event occurs. When to log? What to log?
Cortex provides horizontally scalable, highly available, multi-tenant, long term storage for Prometheus. Loki is a horizontally-scalable, highly-available, multi-tenant log aggregation system inspired by Prometheus. Cortex & Loki are designed in same lines but they differ in the data that flows through this systems i.e metrics vs logs Recently, I have been working on implementing a gRPC based storage system for cortex. which offers plugin your own database add-on feature for storing the metrics.
Helm is a package manager for Kubernetes. A Chart is a Helm package. It contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. Think of it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file. A Release is an instance of a chart running in a Kubernetes cluster. One chart can often be installed multiple times into the same cluster.
The most common problem kubernetes controllers and operators authors face today is to benchmark their tools in large environments with 1000’s of workloads running in it. As controllers & operators come with custom logic to perform an action when a specific event occurs in the cluster to achieve the intended state. Creating 100 node cluster for benchmarking the Kubernetes tools is definitely expensive. Creation, maintainance & deletion is also a tiring job.
gRPC gRPC is a RPC platform initially developed by Google and now a project under CNCF. The letters gRPC are a recursive acronym which means, gRPC Remote Procedure Call. gRPC has two parts, the gRPC protocol, and the data serialization. By default gRPC utilizes Protobuf for serialization, but it is pluggable with any form of serialization you wish to use, with some caveats. HTTP/2 gRPC supports several built in features inherited from http2, such as compressing headers, persistent single TCP connections, cancellation and timeout contracts between client and server.
Role Based Access Control in Kubernetes As we all know role based access control plays a vital role. when we have multiple people using the same resources for different purposes. We need to handle this scenarios by providing the users unique identification mechanism and privileges required for that particular user. RBAC in kubernetes adheres to least privilege principle. Need for RBAC As Kubernetes has tens of resources with many functionalities.
Kubernetes Kubernetes only understands pods not containers. Pod Creation Requests Bare pod RelplicaSet Deployment Multi Container Pods Share access to memory space Connect to each other using localhost Share access to the same volumes (storage abstraction) Tightly coupled. One crashes, all crashes. Same parameters such as config maps. Pod Atomic Unit in Kubernetes is Pod In a pod either all conatiners or none of them run.
The main intention behind writing this blog is to understand docker instructions and it’s capabilities while writing a Dockerfile. In the recent past it’s hard to find an application without a Dockerfile. 😃 INSTRUCTIONS used in Dockerfile FROM MAINTAINER RUN CMD LABEL EXPOSE ENV ADD COPY ENTRYPOINT VOLUME USER WORKDIR ARG ONBUILD STOPSIGNAL HEALTHCHECK SHELL FROM FROM <image> # picks latest by default FROM <image>:<tag> # specific version can be pulled FROM <image>@<digest> # This makes sure we pull the specific image with provided digest, # If image content is changed digest also changes.