コンテンツにスキップ
Kong Logo | Kong Docs Logo
  • ドキュメント
    • API仕様を確認する
      View all API Specs すべてのAPI仕様を表示 View all API Specs arrow image
    • ドキュメンテーション
      API Specs
      Kong Gateway
      軽量、高速、柔軟なクラウドネイティブAPIゲートウェイ
      Kong Konnect
      SaaSのエンドツーエンド接続のための単一プラットフォーム
      Kong AI Gateway
      GenAI インフラストラクチャ向けマルチ LLM AI Gateway
      Kong Mesh
      Kuma と Envoy をベースにしたエンタープライズサービスメッシュ
      decK
      Kongの構成を宣言型で管理する上で役立ちます
      Kong Ingress Controller
      Kubernetesクラスタ内で動作し、Kongをプロキシトラフィックに設定する
      Kong Gateway Operator
      YAMLマニフェストを使用してKubernetes上のKongデプロイメントを管理する
      Insomnia
      コラボレーティブAPI開発プラットフォーム
  • Plugin Hub
    • Plugin Hubを探索する
      View all plugins すべてのプラグインを表示 View all plugins arrow image
    • 機能性 すべて表示 View all arrow image
      すべてのプラグインを表示
      AI's icon
      AI
      マルチ LLM AI Gatewayプラグインを使用してAIトラフィックを管理、保護、制御する
      認証's icon
      認証
      認証レイヤーでサービスを保護する
      セキュリティ's icon
      セキュリティ
      追加のセキュリティレイヤーでサービスを保護する
      トラフィック制御's icon
      トラフィック制御
      インバウンドおよびアウトバウンドAPIトラフィックの管理、スロットル、制限
      サーバーレス's icon
      サーバーレス
      他のプラグインと組み合わせてサーバーレス関数を呼び出します
      分析と監視's icon
      分析と監視
      APIとマイクロサービストラフィックを視覚化、検査、監視
      変革's icon
      変革
      Kongでリクエストとレスポンスをその場で変換
      ログ記録's icon
      ログ記録
      インフラストラクチャに最適なトランスポートを使用して、リクエストと応答データをログに記録します
  • サポート
  • コミュニティ
  • Kongアカデミー
デモを見る 無料トライアルを開始
Kong Mesh
2.10.x (最新)
  • Home icon
  • Kong Mesh
  • Guides
  • Producer and Consumer policies
report-issue問題を報告する
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Kong AI Gateway
  • Plugin Hub
  • decK
  • Kong Ingress Controller
  • Kong Gateway Operator
  • Insomnia
  • Kuma

  • ドキュメント投稿ガイドライン
  • 2.10.x (latest)
  • 2.9.x
  • 2.8.x
  • 2.7.x (LTS)
  • 2.6.x
  • 2.5.x
  • 2.4.x
  • 2.3.x
  • 2.2.x
  • Introduction
    • About service meshes
    • Overview of Kong Mesh
    • How Kong Mesh works
    • Architecture
    • Install
    • Concepts
    • Stages of software availability
    • Version support policy
    • Software Bill of Materials
    • Vulnerability patching process
    • Mesh requirements
    • Release notes
  • Quickstart
    • Deploy Kong Mesh on Kubernetes
    • Deploy Kong Mesh on Universal
  • Kong Mesh in Production
    • Overview
    • Deployment topologies
      • Overview
      • Single-zone deployment
      • Multi-zone deployment
    • Use Kong Mesh
    • Control plane deployment
      • Kong Mesh license
      • Deploy a single-zone control plane
      • Deploy a multi-zone global control plane
      • Zone Ingress
      • Zone Egress
      • Configure zone proxy authentication
      • Control plane configuration reference
      • Systemd
      • Kubernetes
      • kumactl
      • Deploy Kong Mesh in Production with Helm
    • Configuring your Mesh and multi-tenancy
    • Data plane configuration
      • Data plane proxy
      • Configure the data plane on Kubernetes
      • Configure the data plane on Universal
      • Configure the Kong Mesh CNI
      • Configure transparent proxying
      • IPv6 support
    • Secure your deployment
      • Manage secrets
      • Authentication with the API server
      • Authentication with the data plane proxy
      • Configure data plane proxy membership
      • Secure access across services
      • Kong Mesh RBAC
      • FIPS support
    • Kong Mesh user interface
    • Inspect API
      • Matched policies
      • Affected data plane proxies
      • Envoy proxy configuration
    • Upgrades and tuning
      • Upgrade Kong Mesh
      • Performance fine-tuning
      • Version specific upgrade notes
    • Control Plane Configuration
      • Modifying the configuration
      • Inspecting the configuration
      • Store
  • Using Kong Mesh
    • Zero Trust & Application Security
      • Mutual TLS
      • External Service
    • Resiliency & Failover
      • Dataplane Health
      • Service Health Probes
    • Managing incoming traffic with gateways
      • How ingress works in Kuma
      • Delegated gateways
      • Built-in gateways
      • Running built-in gateway pods on Kubernetes
      • Configuring built-in listeners
      • Configuring built-in routes
      • Using the Kubernetes Gateway API
    • Observability
      • Demo setup
      • Control plane metrics
      • Configuring Prometheus
      • Configuring Grafana
      • Configuring Datadog
      • Observability in multi-zone
    • Route & Traffic shaping
      • Protocol support in Kong Mesh
    • Service Discovery & Networking
      • Service Discovery
      • MeshService
      • MeshMultiZoneService
      • HostnameGenerator
      • DNS
      • Non-mesh traffic
      • MeshExternalService
      • Transparent Proxying
  • Policies
    • Introduction
      • What is a policy?
      • What do policies look like?
      • Writing a targetRef
      • Merging configuration
      • Using policies with MeshService
      • Examples
      • Applying policies in shadow mode
    • MeshAccessLog
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshCircuitBreaker
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshFaultInjection
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshHealthCheck
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshHTTPRoute
      • TargetRef support matrix
      • Configuration
      • Examples
      • Merging
    • MeshLoadBalancingStrategy
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshMetric
      • TargetRef support matrix
      • Configuration
      • Prometheus
      • OpenTelemetry
      • Examples
    • MeshPassthrough
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshProxyPatch
      • TargetRef support matrix
      • Configuration
      • Examples
      • Merging
    • MeshRateLimit
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshRetry
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshTCPRoute
      • TargetRef support matrix
      • Configuration
      • Examples
      • Route policies with different types targeting the same destination
    • MeshTimeout
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshTLS
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshTrace
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshTrafficPermission
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshOPA
    • MeshGlobalRateLimit (beta)
    • Previous Policies
      • General notes about Kong Mesh policies
      • How Kong Mesh chooses the right policy to apply
      • Traffic Permissions
      • Traffic Route
      • Traffic Metrics
      • Traffic Trace
      • Traffic Log
      • Locality-aware Load Balancing
      • Fault Injection
      • Health Check
      • Circuit Breaker
      • Retry
      • Timeout
      • Rate Limit
      • Virtual Outbound
      • MeshGatewayRoute
      • OPA policy
  • Guides
    • Federate zone control plane
    • Add a builtin Gateway
    • Add Kong as a delegated Gateway
    • Kubernetes Gateway API
    • Collect Metrics with OpenTelemetry
    • Migration to the new policies
    • Progressively rolling in strict mTLS
    • Producer and consumer policies
    • Configuring inbound traffic with Rules API
    • Upgrading Transparent Proxy
    • Deploy Kong Mesh using Terraform and Konnect
    • Import existing Konnect Kong Mesh deployment to Terraform
  • Enterprise Features
    • Overview
    • HashiCorp Vault CA
    • Amazon ACM Private CA
    • cert-manager Private CA
    • OPA policy support
    • MeshOPA
    • Multi-zone authentication
    • FIPS support
    • Certificate Authority rotation
    • Role-Based Access Control
    • Red Hat
      • UBI Images
      • Red Hat OpenShift Quickstart
    • Windows Support
    • ECS Support
    • Auditing
    • MeshGlobalRateLimit (beta)
    • Verify signatures for signed Kong Mesh images
    • Build provenance
      • Verify build provenance for signed Kong Mesh images
      • Verify build provenance for signed Kong Mesh binaries
  • Reference
    • HTTP API
    • Kubernetes annotations and labels
    • Kuma data collection
    • Control plane configuration reference
    • Envoy proxy template
  • Community
    • Contribute to Kuma
enterprise-switcher-icon 次に切り替える: OSS
On this pageOn this page
  • Prerequisites
  • Basic setup
  • Namespace scoped policies
    • Producer consumer model
  • Testing producer policy
  • Utilizing consumer policy
  • What we’ve learnt?
  • Next steps

このページは、まだ日本語ではご利用いただけません。翻訳中です。

Producer and Consumer policies

With namespace scoped policies in Kong Mesh you can have fine-grained control over policies and how they apply to your workloads. Moreover, this empowers app owners to take advantage of Kubernetes RBAC for policy configuration.

To fully utilize power of namespace scoped policies we need to get familiar with producer consumer model. This guide will help you get comfortable with producer consumer model.

Prerequisites

  • Completed quickstart to set up a zone control plane with demo application

Basic setup

In order to be able to fully utilize namespace scoped policies you need to use MeshService. To make sure that traffic works in our examples let’s configure MeshTrafficPermission to allow all traffic:

echo "apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
  namespace: kuma-demo
  name: mtp
spec:
  targetRef:
    kind: Mesh
  from:
    - targetRef:
        kind: Mesh
      default:
        action: Allow" | kubectl apply -f -

To finish the setup we need to create two additional namespaces with sidecar injection for clients we will be using to communicate with our demo-app:

echo "apiVersion: v1
kind: Namespace
metadata:
  name: first-consumer
  labels:
    kuma.io/sidecar-injection: enabled
---
apiVersion: v1
kind: Namespace
metadata:
  name: second-consumer
  labels:
    kuma.io/sidecar-injection: enabled" | kubectl apply -f -

Now we can create deployment we will be using to communicate with our demo-app from a first-consumer namespace:

kubectl run consumer --image nicolaka/netshoot -n first-consumer --command -- /bin/bash -c "ping -i 60 localhost"

and from the second-consumer namespace:

kubectl run consumer --image nicolaka/netshoot -n second-consumer --command -- /bin/bash -c "ping -i 60 localhost"

You can make now make a couple of requests to our demo app to check if everything is working:

kubectl exec -n first-consumer consumer -- curl -s -XPOST demo-app.kuma-demo:5000/increment

You should see something similar to:

{"counter":"1","zone":"local","err":null}

At this moment our setup looks like this:

Namespace scoped policies

Now that we have our setup we can start playing with policies. Let’s create a simple MeshTimeout policy in kuma-demo namespace:

echo "apiVersion: kuma.io/v1alpha1
kind: MeshTimeout
metadata:
  name: producer-timeout
  namespace: kuma-demo
  labels:
    kuma.io/mesh: default
    kuma.io/origin: zone
spec:
  to:
    - targetRef:
        kind: MeshService
        name: demo-app
      default:
        http:
          requestTimeout: 1s" | kubectl apply -f -

We can now inspect applied policy labels:

kubectl get meshtimeout -n kuma-demo producer-timeout -o jsonpath='{.metadata.labels}'

We should see output like:

{
  "k8s.kuma.io/namespace": "kuma-demo",
  "kuma.io/env": "kubernetes",
  "kuma.io/mesh": "default",
  "kuma.io/origin": "zone",
  "kuma.io/policy-role": "producer",
  "kuma.io/zone": "default"
}

Kong Mesh is adding custom labels to our policy. The one that interests us most at the moment is kuma.io/policy-role. This label indicates the policy role. Possible values of this label are:

  • system - policies applied in system namespace
  • workload-owner - policies that don’t specify spec.from and spec.to sections or specify only spec.from section
  • consumer - policies targeting MeshServices from different namespace in spec.to section or targeting MeshService by labels
  • producer - policies defined in the same namespace as the MeshService they are targeting in their spec.to[].

Producer consumer model

With namespace scoped policies we’ve introduced a producer/consumer model for policies.

A producer is someone who authors and operates a service. A producer can create policies that will be applied by default to any communication with their services. Producer policies will be created in the same namespace as MeshService they target. Producer policies will be synced to other zones.

A consumer is the client of a service. Consumer policies will be applied in the consumer namespace and may target MeshService from different namespaces. Consumer policies take effect only in the consumer namespace. Consumer policies will override producer policies.

Testing producer policy

To test MeshTimeout that we’ve applied in previous steps we need to simulate delays on our requests. To do this we need add header x-set-response-delay-ms to our requests.

We can now make few requests to our demo-app, and we should see timeouts:

kubectl exec -n first-consumer consumer -- curl -s -XPOST demo-app.kuma-demo:5000/increment -H "x-set-response-delay-ms: 2000"

Example output:

upstream request timeout

We should see the same results when making requests from second-consumer namespace:

kubectl exec -n second-consumer consumer -- curl -s -XPOST demo-app.kuma-demo:5000/increment -H "x-set-response-delay-ms: 2000"

Output:

upstream request timeout

Producer policy will be applied on all traffic to kuma-demo as we can see on this diagram:

 
flowchart LR

subgraph first-consumer-ns
first-consumer
end

subgraph second-consumer-ns
second-consumer
end

subgraph kuma-demo-ns
kuma-demo
redis
end

kuma-demo --> redis
first-consumer --producer-timeout--> kuma-demo
second-consumer --producer-timeout--> kuma-demo
  

Utilizing consumer policy

Until now, we were relying on producer policy created previously. Let’s assume that we don’t mind waiting a little longer for the response from demo-app, and we would like to override the timeout just for our namespace. To do so we need to create new policy:

echo "apiVersion: kuma.io/v1alpha1
kind: MeshTimeout
metadata:
  name: consumer-timeout
  namespace: first-consumer
  labels:
    kuma.io/mesh: default
    kuma.io/origin: zone
spec:
  to:
    - targetRef:
        kind: MeshService
        labels:
          k8s.kuma.io/service-name: demo-app
      default:
        http:
          requestTimeout: 3s" | kubectl apply -f -

When we now make requests from the first-consumer namespace all the requests should succeed, but they will take longer:

kubectl exec -n first-consumer consumer -- curl -s -XPOST demo-app.kuma-demo:5000/increment -H "x-set-response-delay-ms: 2000"

We have just applied a consumer policy. The timeout will only be applied in the first-consumer namespace. We can test this by making requests from our second-consumer namespace:

kubectl exec -n second-consumer consumer -- curl -s -XPOST demo-app.kuma-demo:5000/increment -H "x-set-response-delay-ms: 2000"

We should still see timeouts:

upstream request timeout

To better visualize this we can look again at our diagram and see that only traffic from first-consumer will be affected.

 
flowchart LR

subgraph first-consumer-ns
first-consumer
end

subgraph second-consumer-ns
second-consumer
end

subgraph kuma-demo-ns
kuma-demo
redis
end

kuma-demo --> redis
first-consumer --consumer-timeout--> kuma-demo
second-consumer --producer-timeout--> kuma-demo
  

What we’ve learnt?

  • How to apply policy on a namespace
  • What are policy roles and what types can you encounter
  • What are producer and consumer policies
  • How producer and consumer policies interact with each other

Next steps

  • Read more about producer/consumer policies
  • Check out Federate zone control plane guide
Thank you for your feedback.
Was this page useful?
情報が多すぎる場合 close cta icon
Kong Konnectを使用すると、より多くの機能とより少ないインフラストラクチャを実現できます。月額1Mリクエストが無料。
無料でお試しください
  • Kong
    APIの世界を動かす

    APIマネジメント、サービスメッシュ、イングレスコントローラーの統合プラットフォームにより、開発者の生産性、セキュリティ、パフォーマンスを大幅に向上します。

    • 製品
      • Kong Konnect
      • Kong Gateway Enterprise
      • Kong Gateway
      • Kong Mesh
      • Kong Ingress Controller
      • Kong Insomnia
      • 製品アップデート
      • 始める
    • ドキュメンテーション
      • Kong Konnectドキュメント
      • Kong Gatewayドキュメント
      • Kong Meshドキュメント
      • Kong Insomniaドキュメント
      • Kong Konnect Plugin Hub
    • オープンソース
      • Kong Gateway
      • Kuma
      • Insomnia
      • Kongコミュニティ
    • 会社概要
      • Kongについて
      • お客様
      • キャリア
      • プレス
      • イベント
      • お問い合わせ
  • 利用規約• プライバシー• 信頼とコンプライアンス
© Kong Inc. 2025