- Features and Benefits
- Using Ambassador Edge Stack in Your Organization
- Ambassador Edge Stack vs. Other Software
- Certified Builds
- Ambassador Edge Stack Architecture
- Ambassador Edge Stack Deployment Architecture
- Continuous Delivery, Declarative Config, and GitOps
- Microservices API Gateways
- Rate Limiting Concepts
- Self-Service Routing and Deployment Control
- Safely Testing in Production
- OAuth & OIDC Overview
- Why Ambassador Edge Stack Uses Envoy Proxy (External Link)
- Configuring Ambassador Edge Stack
- Mapping Services
- Canary Releases
- Circuit Breakers
- Cross Origin Resource Sharing
- Header-based routing
- Host Header
- Host CRD
- Prefix Regex
- Rate Limits
- Remove Request Headers
- Remove Response Headers
- Add Request Headers
- Add Response Headers
- Automatic Retries
- Routing TCP Connections
- Traffic Shadowing
- Developer Portal
- Filter Reference
- Statistics and Monitoring
In cloud environments, provisioning a readily available network load balancer with Ambassador is the best option for handling ingress into your Kubernetes cluster. When running Kubernetes on a bare-metal setup, where network load balancers are not available by default, we need to consider different options for exposing Ambassador.
The simplest way to expose an application in Kubernetes is via a
NodePort service. In this configuration, we create the Ambassador service and identify
type: NodePort instead of
LoadBalancer. Kubernetes will then create a service and assign that service a port to be exposed externally and direct traffic to Ambassador via the defined
---apiVersion: v1kind: Servicemetadata:name: ambassadorspec:type: NodePortports:- name: httpport: 8088targetPort: 8080nodePort: 30036 # Optional: Define the port you would like exposedprotocol: TCPselector:service: ambassador
NodePort leaves Ambassador isolated from the host network, allowing the Kubernetes service to handle routing to Ambassador pods. You can drop-in this YAML to replace the
LoadBalancer service in the YAML installation guide and use
http://<External-Node-IP>:<NodePort>/ as the host for requests.
When running Ambassador on a bare-metal install of Kubernetes, you have the option to configure Ambassador pods to use the network of the host they are running on. This method allows you to bind Ambassador directly to port 80 or 443 so you won't need to identify the port in requests.
This can be configured by setting
hostNetwork: true in the Ambassador deployment.
dnsPolicy: ClusterFirstWithHostNet will also need to set to tell Ambassador to use KubeDNS when attempting to resolve mappings.
---apiVersion: apps/v1kind: Deploymentmetadata:name: ambassadorspec:replicas: 1selector:matchLabels:service: ambassadortemplate:metadata:annotations:sidecar.istio.io/inject: "false"labels:service: ambassadorspec:+ hostNetwork: true+ dnsPolicy: ClusterFirstWithHostNetserviceAccountName: ambassadorcontainers:- name: ambassadorimage: quay.io/datawire/ambassador:1.1.0resources:limits:cpu: 1memory: 400Mirequests:cpu: 200mmemory: 100Mienv:- name: AMBASSADOR_NAMESPACEvalueFrom:fieldRef:fieldPath: metadata.namespacelivenessProbe:httpGet:path: /ambassador/v0/check_aliveport: 8877initialDelaySeconds: 30periodSeconds: 3readinessProbe:httpGet:path: /ambassador/v0/check_readyport: 8877initialDelaySeconds: 30periodSeconds: 3restartPolicy: Always
This configuration does not require a defined Ambassador service, so you can remove that service if you have defined one.
Note: Before configuring Ambassador with this method, consider some of the functionality that is lost by bypassing the Kubernetes service including only having one Ambassador able to bind to port 8080 or 8443 per node and losing any load balancing that is typically performed by Kubernetes services.
Join our Slack channel to ask any questions you have regarding running Ambassador on a bare metal installation.