Cloud Native Culture

Application Resource   I hope you remember this question in the previous blog: " But how does the Argo CD operator know about the source and destination? ". These all are declared in a custom resource definition(CRD) called Application . It has a source field, a destination field, and many more fields. In order to differentiate b/w source and destination, simply ask this question: For Source : From where to fetch/pull the manifest or configuration files?? For Destination : And where to deploy these manifests or configuration files?? So, the Argo CD operator i.e. application controller uses application resources to achieve the desired state in the cluster with the help of the reconciliation concept. Let's understand the terminologies used in the Application. Argo CD Concepts and Terminologies ?? Terminologies to be used while writing an application resource: The application has 3 main components: Destination : This refers to clusters to which manifest to be deployed or t

Why Argo CD ?? Because it fulfills all the points of the GitOps principle . As it extends the benefits of declarative specifications, acting as a GitOps Operator, follows a pull-based approach,  and considers Git as a source of truth for configuration management. It follows a pattern of reconciliation i.e. continuously performing a control loop every 3 minutes to achieve the desired state by fetching the desired configuration from Git. Let’s understand it in more detail, how can we achieve or implement GitOps using Argo CD ?? We all know that every company and every developer uses Git as a source code management software to store code. Developers can commit their infrastructure configurations, such as Kubernetes resource manifest, in Git to create the environment needed for application deployment. Once a developer implements a feature( with new applications and Kubernetes configurations) and merges the main branch. With the help of the GitOps agent or GitOps operator, Argo CD will imme

Here we will discuss: "What is GitOps", and "What are its 4 important principles". And lastly, "Why GitOps operator follow a pull-based model ?". What is GitOps ?? GitOps is made up of two words: Git and Ops . Git is where you keep your desired manifest(or configurations) that you want to deploy in your cluster(or environment). And Ops refers to Operation. Operation refers to the environment where the things are operated to ensure that the actual state or live state of that environment must be the same as the desired state in the git. To achieve that from the actual state to the desired state an operation is performed inside the environment.  Such an environment could be a Kubernetes cluster. So, anything that you want to deploy in the Kubernetes simply put it in the git. From git, the GitOps operator(i.e. Argo CD) will deploy to the Kubernetes cluster. To understand the GitOps better we need to understand 4 principles of it: 4 Principles of GitOps: 1.

  Prometheus Architecture Look at the below figure, and we can see that Prometheus has major 3 things:  to pull Metrics ,  store it in the Time-Series database , a nd  allow third parties to retrieve metrics using PromQL Metrics are mainly pulled from 3 sources: PushGateway , Exporters , and Instrumentation . These pulled metrics are then stored in a time-series database. Later time-series stored metrics are used by third parties such as Prometheus Web UI ,  Alertmanager , and Grafana . Components of Prometheus: There are 3 main components of Prometheus: Retrieval/Pull Metrics This component of Prometheus is mainly responsible for pulling metrics from targets. Targets can be exporters ,   instrumentation , and pushgateway . Time Series Database Once the retrieval collects data from the target, then it transfers to a time-series database. The data are stored in the form of a metric. Each metric is identified by its name and labels. HTTP Server It allows collected time-series data from