Skip to main content

HTTP Egress

In order to direct traffic from an application on the CloudFlow platform to an alternate Origin you can deploy CloudFlow's Egress Module as an HTTP extension.

Egress Module Deployment

This guide will walk you through deploying the CloudFlow Egress reverse proxy. The Egress reverse proxy is a simple reverse proxy that normalizes and routes requests to an external service. You can read more about the Egress technical details. You will need the following Kubernetes resources to deploy the Egress reverse proxy:

ConfigMap

Create the following ConfigMap defining an egress.json file:

egress-configmap.yaml
kind: ConfigMap
apiVersion: v1
metadata:
name: egress-config
namespace: default
data:
egress.json: |
{
"origin": {
"address":"my-external-service.example.com",
"enable_sni":true
},
"alternate_origins": {
"another_endpoint": {
"address":"my-external-service2.example.com"
}
}
}

This example will define a default origin routing traffic to my-external-service.example.com. The default origin will be used when no other origin is specified. The section-origin HTTP request header can be used to specify an alternate origin based on the matching key and value, e.g. another_endpoint.

Deployment

The deployment object is defined via the following YAML example:

egress-deployment.yaml
kind: Deployment
apiVersion: apps/v1
metadata:
name: egress
namespace: default
labels:
app: egress
spec:
replicas: 2
selector:
matchLabels:
app: egress
template:
metadata:
labels:
app: egress
spec:
volumes:
- name: config-mount
configMap:
name: egress-config
containers:
- name: proxy
image: 'gcr.io/section-io/k8s-egress:2.1.1'
ports:
- containerPort: 80
protocol: TCP
env:
- name: CLOUDFLOW_PROXY_NAME
value: egress
- name: REDIS_HOST
value: 127.0.0.1
- name: PROXY_REGO_KEY
value: abc
- name: LIST_KEY_PREFIX
value: abc
- name: LIST_KEY_SUFFIX
value: abcingress
resources:
limits:
cpu: '0.2'
memory: 400Mi
requests:
cpu: '0.2'
memory: 400Mi
volumeMounts:
- name: config-mount
readOnly: true
mountPath: /opt/proxy_config
livenessProbe:
httpGet:
path: /.well-known/section-io/egress-status
port: 80
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 10
periodSeconds: 5
successThreshold: 1
failureThreshold: 3
readinessProbe:
httpGet:
path: /.well-known/section-io/egress-status
port: 80
scheme: HTTP
timeoutSeconds: 1
periodSeconds: 10
successThreshold: 1
failureThreshold: 3
imagePullPolicy: Always
restartPolicy: Always
terminationGracePeriodSeconds: 30
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1

Note: The environment variables are not explicitly used but are required for the container to function properly.

Service

In order to route traffic to the egress container, we need to define a service. The service is defined via the following YAML example:

egress-service.yaml
apiVersion: v1
kind: Service
metadata:
name: egress-service
spec:
selector:
app: egress
ports:
- protocol: TCP
port: 8080
targetPort: 80

In order to route traffic to the egress service we will use the following Nginx example below.

location / {
proxy_set_header X-Forwarded-For $http_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
proxy_set_header Host $host;
proxy_pass http://egress-service:8080;
}