Proxy Sidecar with Kubernetes

This guide explains how to deploy the Qpoint Proxy as a sidecar container in your Kubernetes pods. This approach allows you to route traffic through the Qpoint Proxy for individual pods without needing to deploy it as a separate service.

We'll skip Certificate Installation in this guide. See the Kubernetes Connect guide for additional information on how to supply certificates.

Prerequisites

• Kubernetes cluster

• kubectl command-line tool

• Qpoint registration token

Create a Kubernetes Secret for the Registration Token

Instead of passing the registration token directly in the pod specification, we'll create a Kubernetes Secret to store it securely:

apiVersion: v1
kind: Secret
metadata:
  name: qpoint-registration-token
type: Opaque
stringData:
  token: "your-registration-token-here"

Save this as qpoint-secret.yaml and apply it:

kubectl apply -f qpoint-secret.yaml

Create the Pod Specification

Here's an example pod specification that includes the Qpoint Proxy as a sidecar:

apiVersion: v1
kind: Pod
metadata:
  name: qpoint-sidecar-example
spec:
  initContainers:
    - name: qpoint-init
      image: us-docker.pkg.dev/qpoint-edge/public/kubernetes-qpoint-init:v0.0.9
      env:
        - name: PORT_MAPPING
          value: "10443:443,10080:80"
        - name: ACCEPT_UIDS
          value: "1010"  # Accept the proxy UID
        - name: ACCEPT_GIDS
          value: "1010"  # Accept the proxy GID
      securityContext:
        capabilities:
          add: ["NET_ADMIN"]
  containers:
  - name: main-container
    image: curlimages/curl
    command: ["sh"]
    stdin: true
    tty: true
    securityContext:
      capabilities:
        add: ["NET_ADMIN"]
  - name: qpoint-proxy
    image: us-docker.pkg.dev/qpoint-edge/public/qpoint:v0.1.6
    imagePullPolicy: IfNotPresent
    args:
      - proxy
      - --registration-token=$(QPOINT_REGISTRATION_TOKEN)
      - --envoy-log-level=error
      - --log-level=info
      - --dns-lookup-family=V4_ONLY
      - --access-log
    env:
      - name: QPOINT_REGISTRATION_TOKEN
        valueFrom:
          secretKeyRef:
            name: qpoint-registration-token
            key: token
    ports:
      - name: e-https
        containerPort: 10443
        protocol: TCP
      - name: status
        containerPort: 10001
        protocol: TCP
    startupProbe:
      httpGet:
        path: /readyz
        port: status
      initialDelaySeconds: 3
      periodSeconds: 5
      timeoutSeconds: 2
      successThreshold: 1
      failureThreshold: 20
    readinessProbe:
      httpGet:
        path: /readyz
        port: status
      initialDelaySeconds: 3
      periodSeconds: 5
      timeoutSeconds: 2
      successThreshold: 1
      failureThreshold: 1
    livenessProbe:
      httpGet:
        path: /healthz
        port: status
      initialDelaySeconds: 3
      periodSeconds: 10
      timeoutSeconds: 2
      successThreshold: 1
      failureThreshold: 3
    resources: {}

Note: The main container also needs the NET_ADMIN capability for the iptables rules to take effect.

Save this as qpoint-sidecar-pod.yaml.

Deploy the Pod

Apply the pod specification:

kubectl apply -f qpoint-proxy-sidecar.yaml

Verify the Deployment

Check if the pod is running:

kubectl get pods qpoint-sidecar-example

You should see the pod in the "Running" state with 2/2 containers ready.

Testing the Proxy

To test if the proxy is working, you can exec into the main container and make a request:

kubectl exec -it qpoint-sidecar-example -c main-container -- sh

Once inside the container, you can use curl to make a request:

curl -I https://example.com

This request should be routed through the Qpoint Proxy sidecar.

Notes

• The qpoint-init container sets up iptables rules to route traffic through the proxy.

• The main container and the proxy container both have the NET_ADMIN capability to allow network configuration.

• The registration token is securely stored in a Kubernetes Secret and injected into the proxy container as an environment variable.

• Adjust the PORT_MAPPING, ACCEPT_UIDS, and ACCEPT_GIDS in the qpoint-init container as needed for your specific use case. Qproxy always runs as User / Group 1010.

• You may need to adjust resource requests and limits for the proxy container based on your requirements.

This setup allows you to use the Qpoint Proxy on a per-pod basis, giving you fine-grained control over which pods use the proxy.