As an operator of Gloo, it’s important to understand how Gloo manages it’s configuration, and how this can fit into the processes for managing production environments at your enterprise.
How to configure Gloo.
Kubernetes was built to support declarative configuration management. With Kubernetes, you can describe the desired state of your application through a set of configuration files, and simply run kubectl apply -f .... Kubernetes abstracts away the complexity of computing a diff and redeploying pods, services, or other objects that have changed, while making it easy to reason about the end state of the system after a configuration change. GitOps Configuration changes inherently create risk, in that the new configuration may cause a disruption in a running application.
This document shows how to secure your ingress traffic using gloo and cert-manager. We will deploy everything to minikube. With minor adjustments can be applied to any Kubernetes cluster. Pre-requisites A DNS that your control and supported by cert-manager. In this example we used ‘test.solo.io’ domain that’s managed by AWS Route53. Kubernets cluster (this document was test with minikube and linux, other OSes\clusters should work with proper adjustments). Setup Setup your DNS In this example we used the domain name ‘test.
At it’s core, Gloo is a simple product that adheres to the declarative infrastructure model: - It watches the current state, known as a snapshot, consisting of proxies, secrets, endpoints, upstreams, and artifacts. - It runs an event loop that, when the snapshot changes, reconciles it with the current state and applies any necessary changes. GitOps with Gloo Following the GitOps methodology, custom Gloo configuration can be stored in a version control repo, and controlling how that configuration is reviewed, merged, and deployed can help mitigate operational risk.
How to monitor and trace within your Gloo setup.
Usage Statistics Gloo will periodically collect usage information from running instances. The details of this collection can be found here. The checks are performed on each invocation of glootcl after a given interval. This interval can be changed by setting the env var CHECKPOINT_TIMEOUT in milliseconds. This information icludes the following: Glooctl version Architecture Operating System To turn off these checks simply set CHECKPOINT_DISABLE=1