| Workflow Type | Description | Trigger Mechanism |
|---|---|---|
| Push-based workflow | You push code or configuration changes directly to a pipeline, which then builds and deploys artifacts. | Manual git push or automated CI pipeline trigger |
| Pull-based workflow (GitOps) | A Git repository serves as the single source of truth. A GitOps operator continuously reconciles your cluster with the repo. | Operator polling or webhook-based syncing |
Push-based Workflow
With a push-based approach, your CI server (Azure DevOps, GitHub Actions, etc.) listens for changes in your application repository. When you commit or merge code, the pipeline:Push-based pipelines are straightforward and give you direct control over each deployment step. They work well if you prefer an explicit trigger model.
Pull-based Workflow (GitOps)
In a GitOps (pull-based) model, you store your Kubernetes manifests alongside application code or in a dedicated Git repo. A GitOps operator (Flux, Argo CD) watches the repo and applies changes automatically:GitOps ensures that your cluster’s live state automatically converges with the declared Git state. This model enhances auditability, reversibility, and compliance.
- Azure Monitor for Containers: Collects metrics, logs, and health data for nodes and pods.
- Azure Log Analytics: Enables querying of container logs using Kusto Query Language (KQL).
- Application Insights: Offers distributed tracing, exception tracking, and performance monitoring for your applications.
| Feature | Purpose | Example Query | |
|---|---|---|---|
| Container CPU & Memory Metrics | Track resource utilization | `InsightsMetrics | where Name == “cpuUsageNanoCores”` |
| Pod Log Collection | Aggregate stdout/stderr logs from containers | `ContainerLog | where PodName == “myapp”` |
| Distributed Tracing | Monitor service-to-service calls | View in Application Insights UI |