Ingress در Kubernetes باید ترافیک خارجی را به Serviceها برساند — با TLS، path routing، و مشاهده‌پذیری. خیلی تیم‌ها بین این گزینه‌ها می‌مانند:

NGINX Ingress  →  آشنا، annotation-heavy
Envoy خام       →  قدرتمند، بدون K8s control plane
Gateway API     →  استاندارد آینده، نیاز به implementation

Contour پاسخ Heptio/VMware (و حالا جامعه CNCF) است:

An open source Kubernetes ingress controller providing the control plane for the Envoy edge and service proxy

یعنی Contour خود Envoy نیست — مدیریت‌کنندهٔ Envoy است: Kubernetes API را می‌بیند و از طریق xDS به Envoy config می‌دهد.

طبق CNCF: پذیرش ۷ ژوئیه ۲۰۲۰ در سطح Incubating.

مشکل: Ingress بدون data plane مدرن

Ingress resource alone:
  فقط قرارداد — نیاز به controller

NGINX Ingress:
  بالغ — مدل annotation، کمتر «Envoy-native»

Contour:
  Contour (control) + Envoy (data)
  Ingress + HTTPProxy + Gateway API
  همان قابلیت‌های L7 که در [Envoy](/blog/envoy-proxy-cloud-native-data-plane-guide/) دارید

Contour برای تیم‌هایی است که Envoy را به‌عنوان edge می‌خواهند، اما با تجربهٔ Kubernetes-native (CRD، status، Helm).

Contour چیست؟

Contour یک Kubernetes Ingress Controller است که:

• Envoy را به‌عنوان reverse proxy با عملکرد بالا اجرا می‌کند
• خودش management server (xDS) برای آن Envoyها است
• منابع Ingress، HTTPProxy، و اختیاری Gateway API را تماشا می‌کند
• Service، Endpoints، Secret را به CDS/RDS/EDS/SDS ترجمه می‌کند

Site: projectcontour.io
CNCF page: cncf.io/projects/contour
Repo: github.com/projectcontour/contour

Origin: Heptio → VMware Tanzu ecosystem → CNCF
License: Apache 2.0

تاریخچه

هر دو Contour و Envoy Gateway از Envoy استفاده می‌کنند؛ Contour مسیر بالغ Ingress/HTTPProxy + Gateway را نگه می‌دارد، Envoy Gateway بیشتر روی Gateway API خالص تمرکز دارد.

معماری: Contour + Envoy

طبق Architecture docs:

Kubernetes API
  Ingress / HTTPProxy / Gateway API / Service / Endpoints / Secret
        │  watch (controller-runtime)
        ▼
┌─────────────────┐     gRPC xDS      ┌─────────────┐
│ Contour         │◄──────────────────►│ Envoy       │
│ Deployment      │   CDS RDS EDS …    │ DaemonSet   │
│ (leader elect)  │                    │ or Deploy   │
└─────────────────┘                    └──────┬──────┘
                                              │
                                         LoadBalancer / NLB
                                              │
                                         Clients → Services → Pods

نقش‌ها

Envoy اگر Contour موقتاً نباشد gracefully retry می‌کند — ترتیب start حیاتی نیست.

HA Contour

• چند replica با leader election
• همه instanceها می‌توانند xDS به Envoy بدهند
• فقط leader status را به API می‌نویسد
• در ترافیک بالای Envoy→Contour، HA مقیاس عملیاتی می‌دهد

استقرار Envoy

Probes: Envoy /ready روی admin؛ Contour liveness /healthz و readiness دسترسی به API.

سه سطح API برای routing

۱. Ingress (استاندارد)

سازگار با اکوسیستم موجود؛ با Helm اغلب ingressClassName: contour.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin
spec:
  ingressClassName: contour
  rules:
  - host: httpbin.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: httpbin
            port:
              number: 80

۲. HTTPProxy (CRD Contour)

قابلیت‌های غنی‌تر از Ingress کلاسیک:

• virtual host با FQDN
• path routing، header/method matching
• weight / mirroring / retry / timeout
• includes — ترکیب routeها بین namespaceها
• TCPProxy برای TCP/TLS passthrough
• TLS با Secret و TLSCertificateDelegation

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: www
  namespace: default
spec:
  virtualhost:
    fqdn: www.example.com
    tls:
      secretName: www-tls   # یا admin-ns/wildcard-secret با delegation
  routes:
  - conditions:
    - prefix: /
    services:
    - name: web
      port: 80
      weight: 90
    - name: web-canary
      port: 80
      weight: 10

۳. Gateway API

Contour هدف پشتیبانی core و extended Gateway API را دارد.

• یک Gateway ≈ یک جفت Contour+Envoy (۱:۱ در مدل Contour)
• HTTPRoute / TLSRoute و منابع مرتبط
• دو روش نصب: static provisioning و dynamic (Gateway Provisioner)

حتی با Gateway فعال، می‌توانید هنوز Ingress/HTTPProxy را (با محدودیت‌ها و listenerهای خاص) استفاده کنید — مفید برای مهاجرت تدریجی.

TLS، cert-manager، Delegation

TLS termination

• Secret استاندارد Kubernetes (tls.crt / tls.key)
• SNI اجباری برای virtual host صحیح
• یکپارچگی رایج با cert-manager — راهنمای رسمی Contour موجود است

TLSCertificateDelegation

برای wildcard cert در namespace admin که تیم‌های دیگر باید ارجاع دهند — بدون کپی Secret:

apiVersion: projectcontour.io/v1
kind: TLSCertificateDelegation
metadata:
  name: wildcard-delegate
  namespace: www-admin
spec:
  delegations:
  - secretName: example-com-wildcard
    targetNamespaces:
    - example-com
    # یا "*" برای همه

در HTTPProxy:

tls:
  secretName: www-admin/example-com-wildcard

برای Ingress v1 از annotation projectcontour.io/tls-cert-namespace استفاده می‌شود.

قابلیت‌های عملیاتی مهم

همه روی قدرت Envoy سوارند — Contour آن‌ها را از Kubernetes قابل‌اعلام می‌کند.

نصب

پیش‌نیاز

• Kubernetes cluster
• kubectl (+ اختیاری Helm)
• برای production: LoadBalancer / NLB و DNS

Helm (سریع)

helm repo add projectcontour https://charts.projectcontour.io
# یا طبق docs جاری projectcontour — repository ممکن است به‌روز شود
helm repo update

helm install my-release contour/contour \
  --namespace projectcontour \
  --create-namespace

مستندات رسمی Getting Started چند گزینه دارد: YAML خام، Helm، Gateway provisioner — همیشه getting-started نسخهٔ روز را چک کنید.

Gateway Provisioner (dynamic)

# مفهومی — از manifests رسمی
# 1) نصب provisioner
# 2) GatewayClass با controllerName: projectcontour.io/gateway-controller
# 3) Gateway در namespace projectcontour

با ساخت Gateway، Contour+Envoy مربوطه provision می‌شوند. می‌توانید routing را همچنان با Ingress تعریف کنید.

تست سریع

# static Envoy service
kubectl -n projectcontour port-forward svc/envoy 8888:80

# یا با provisioner
kubectl -n projectcontour port-forward svc/envoy-contour 8888:80

curl -H "Host: httpbin.example.com" http://127.0.0.1:8888/

مقایسه Contour vs Envoy Gateway vs NGINX

Contour جایگزین mesh نیست — ingress/edge است.

Observability و troubleshooting

kubectl -n projectcontour get pods
kubectl -n projectcontour logs deploy/contour --tail=100
kubectl -n projectcontour logs ds/envoy --tail=50   # یا deploy/envoy

# status روی HTTPProxy
kubectl describe httpproxy www

Admin Envoy و metrics Prometheus را محدود و مانیتور کنید — مثل هر Envoy deployment.

امنیت

• Contour به Secrets دسترسی دارد — RBAC حداقل و namespace‌بندی
• TLS delegation را فقط به namespaceهای لازم بدهید (* با احتیاط)
• External auth و rate limit برای edge
• Threat model رسمی Contour را در docs امنیت بخوانید
• به‌روزرسانی همگام Contour و تصویر Envoy همراه chart

تصاویر از Harbor؛ توزیع در مقیاس با Dragonfly.

ارتباط با stack شما

Internet
   │
   ▼
LoadBalancer / NLB
   │
   ▼
Envoy (Contour-managed)     ← data plane
   │ xDS
Contour Deployment          ← control plane
   │ watch
Ingress / HTTPProxy / Gateway API
   │
   ▼
Services → Pods
   ([containerd](/blog/containerd-container-runtime-guide/), [Cilium](/blog/cilium-ebpf-kubernetes-networking/), [CoreDNS](/blog/coredns-kubernetes-dns-guide/))

TLS secrets ← [cert-manager](/blog/cert-manager-kubernetes-tls-certificates/)
GitOps     ← [Argo CD](/blog/argo-project-kubernetes-gitops-cicd/)

Dapr پشت Contour می‌ماند (app runtime)؛ Contour فقط ورودی north-south را مدیریت می‌کند.

Best practices

1. در production از Deployment Envoy با anti-affinity اگر drain تمیز مهم است
2. Contour را HA (≥۲ replica) کنید
3. برای wildcard از TLSCertificateDelegation استفاده کنید نه کپی Secret
4. ingressClassName را صریح بگذارید اگر چند controller دارید
5. مهاجرت تدریجی: Ingress → HTTPProxy → Gateway API
6. PROXY protocol را با NLB درست کنید تا IP واقعی client بماند
7. Resource limits Contour/Envoy را از راهنمای رسمی تنظیم کنید
8. Metrics + alert روی xDS و upstream 5xx
9. GitOps برای HTTPProxy/Gateway
10. نسخه chart Contour را با Envoy bundled هم‌تراز نگه دارید

چه زمانی Contour؟

✅ استفاده کنید

• می‌خواهید Envoy در edge با تجربه Kubernetes
• نیاز به HTTPProxy (includes، delegation، weights)
• Gateway API + حفظ Ingress موجود
• یکپارچگی با cert-manager و AWS NLB

⚠️ شاید نه

• فقط چند Ingress ساده و تیم NGINX — مهاجرت اجباری نیست
• نیاز به AI Gateway تخصصی — Envoy AI Gateway را جدا ببینید
• بدون آمادگی ops برای دو جزء Contour+Envoy

طبق CNCF project page، پروژه Incubating است؛ قبل از انتخاب، وضعیت community و roadmap نسخهٔ جاری را چک کنید (health score در LFX متغیر است).

جمع‌بندی

Contour پلی است بین قراردادهای Kubernetes (Ingress/Gateway) و قدرت Envoy — بدون اینکه هر تیم Envoy خام را با دست پیکربندی کند.

قدم بعدی

1. Getting Started — YAML یا Helm روی kind/dev
2. یک Ingress با ingressClassName: contour
3. همان سرویس را به HTTPProxy با weight canary تبدیل کنید
4. cert-manager + TLS روی HTTPProxy
5. (اختیاری) Gateway provisioner و یک HTTPRoute

منابع

• CNCF Contour
• projectcontour.io
• Architecture
• Getting Started
• Gateway API with Contour
• TLS Certificate Delegation
• GitHub — projectcontour/contour
• Envoy Proxy (مقاله P30Light)

منتشر شده در P30Light — بخش زیرساخت و سرور.