ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、こちらまでご連絡ください。

CNE Kubernetes Ready: Kubernetes Readyデプロイメントのためのネットワーク構築

Kubernetes Ready デプロイメントは、Helm チャートによって作成された liferay-default Kubernetes サービスを介して Liferay DXP を公開します。外部トラフィックは、インフラストラクチャに応じて、イングレスコントローラ、ゲートウェイAPI実装、ロードバランサ、サービスメッシュ、CDNフロントエンドのエッジプロキシなど、プラットフォームが管理するネットワーク層を介してこのサービスに到達します。

サポートされているイングレスおよびルーティングオプションには、NGINX、Traefik、Envoy、Istio、Contour、AWS ALB、GKE Ingress、Azure Application Gateway、OpenShift Routes、およびCloudflare、Akamai、Fastly、CloudFrontなどのエッジCDNが含まれます。

ネットワークモデル

liferay-default チャートは、2 つの Kubernetes サービスを公開します。

サービス	港	目的	外部トラフィック
`liferay-default` (ClusterIP)	`http: 8080`、 `クラスター: 7800`	Liferay DXPへの主要な入り口。外部トラフィックをポート `8080` のみにルーティングします。	はい（ `8080` で）
`liferay-default-headless`	`http: 8080`、 `クラスター: 7800`	クラスタリンク通信のための安定したポッドごとのDNS	いいえ

外部トラフィックは、ポート liferay-default のポート 8080 にのみ到達する必要があります。

重要

ポート 7800 を外部に公開しないでください。 Liferayは、StatefulSetレプリカ間のクラスタリングとセッションレプリケーションのために、このチャネルを内部的に使用します。

転送ヘッダーの設定

Liferayは、イングレス層またはプロキシ層によって追加された転送ヘッダーを信頼する必要があります。これらの設定がないと、Liferay はリダイレクト、メール、OAuth コールバック、および生成されたリンクにおいて、誤った絶対 URL を生成する可能性があります。

以下の環境変数を values.yaml に追加してください。

customEnv:
  x-liferay-forwarded:
    - name: LIFERAY_WEB_PERIOD_SERVER_PERIOD_FORWARDED_PERIOD_PORT_PERIOD_ENABLED
      value: "true"

    - name: LIFERAY_WEB_PERIOD_SERVER_PERIOD_FORWARDED_PERIOD_PROTOCOL_PERIOD_ENABLED
      value: "true"

    - name: LIFERAY_WEB_PERIOD_SERVER_PERIOD_FORWARDED_PERIOD_HOST_PERIOD_ENABLED
      value: "true"

一般的なネットワーク要件

使用する侵入技術に関わらず、本番環境への導入では一般的に以下の調整が必要となります。

懸念	なぜそれが重要なのか
WebSocketとSSEのサポート	コラボレーション機能、通知、およびライブアップデートは、長時間の接続を使用します。
ヘッダーサイズの制限	認証トークンとクッキーは、デフォルトのプロキシ制限を超える可能性があります。
読み取りタイムアウトとアイドルタイムアウト	インポート、エクスポート、公開、および大規模なリクエストには数分かかる場合があります。
スティッキーセッション	オプションですが、セッションレプリケーション中のフェイルオーバー問題を軽減できます。
圧縮	Tomcatではレスポンスの圧縮ではなく、エッジサイド圧縮を優先します。

ゲートウェイAPI

プラットフォームがEnvoy Gateway、Istio Gateway API、Contour、Kong、またはその他のGateway API実装を標準としている場合は、Gateway APIを使用できます。

チャートの HTTPRoute サポートを有効にします。

network:
  enabled: true
  gatewayName: liferay-gateway
  endpointRef: http
  forceHttpsRedirect: true

  hostnames:
    - "liferay.example.com"

  timeouts:
    backendRequest: 300s
    request: 300s

このチャートは HTTPRouteを作成しますが、 Gateway、リスナー、TLS 証明書、およびゲートウェイのライフサイクル管理については、プラットフォームが引き続き責任を負います。

Kubernetes Ingressコントローラー

プラットフォームが標準の Kubernetes Ingress リソースを使用している場合は、チャートのネットワークレイヤーを無効にして、 Ingress リソースを別途作成します。

NGINX Ingress Controllerとcert-managerを使用した例を以下に示します。

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: liferay
  namespace: liferay

  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/proxy-body-size: "100m"
    nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "300"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"

spec:
  ingressClassName: nginx

  tls:
    - hosts:
        - liferay.example.com
      secretName: liferay-example-tls

  rules:
    - host: liferay.example.com

      http:
        paths:
          - path: /
            pathType: Prefix

            backend:
              service:
                name: liferay-default

                port:
                  name: http

Traefik、HAProxy Ingress、その他のコントローラーにも同様のパターンが存在します。

クラウドロードバランサー

マネージドKubernetesプラットフォームでは、一般的にKubernetesリソースからクラウドネイティブなロードバランサーがプロビジョニングされます。

プラットフォーム	典型的な統合
Amazon EKS	AWS Load Balancer ControllerとALB
Google GKE	GKEイングレスまたはゲートウェイコントローラー
Azure AKS	コンテナ向けアプリケーションゲートウェイ（AGIC）

このような環境では、TLSは通常、トラフィックがKubernetesクラスターに到達する前にクラウドロードバランサーで終端されます。

サービスメッシュ

お使いの環境でIstioやLinkerdなどのサービスメッシュを使用している場合は、スタンドアロンのイングレスコントローラーではなく、メッシュのイングレスゲートウェイを介してLiferayを公開してください。

以下は、Istio GatewayとVirtualServiceの例です。

apiVersion: networking.istio.io/v1
kind: Gateway

metadata:
  name: liferay-gateway
  namespace: liferay

spec:
  selector:
    istio: ingressgateway

  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS

      hosts:
        - "liferay.example.com"

      tls:
        mode: SIMPLE
        credentialName: liferay-example-tls

---
apiVersion: networking.istio.io/v1
kind: VirtualService

metadata:
  name: liferay
  namespace: liferay

spec:
  hosts:
    - "liferay.example.com"

  gateways:
    - liferay-gateway

  http:
    - timeout: 300s

      route:
        - destination:
            host: liferay-default

            port:
              number: 8080

OpenShiftルート

OpenShift 環境では、 Ingress の代わりにネイティブの Route リソースを介して Liferay を公開できます。

例:

apiVersion: route.openshift.io/v1
kind: Route

metadata:
  name: liferay
  namespace: liferay

spec:
  host: liferay.example.com

  to:
    kind: Service
    name: liferay-default

  port:
    targetPort: http

  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

CDNおよびエッジプロキシの導入

多くの本番環境におけるデプロイメントでは、Kubernetesの前にCDNまたはエッジプロキシが配置されます。

選択肢は以下のとおりです。

クラウドフレア
赤井
ファストリー
Amazon CloudFront

これらのプラットフォームは一般的に以下の機能を提供します。

TLSの終了
Webアプリケーションファイアウォール（WAF）
DDoS攻撃対策
グローバルエッジキャッシング
ボットフィルタリング

一般的な導入パターンは2つ存在する。

パブリックイングレスの前に設置されたCDN

CDNはリクエストをパブリックなKubernetesイングレスまたはロードバランサーに転送します。可能な限りオリジンへの直接アクセスを制限し、リクエストがエッジレイヤーを経由するようにする。

クラスターへの専用トンネル

一部の導入事例では、エッジプラットフォームをプライベートトンネルまたはプライベートネットワークを介してKubernetesに直接接続します。

例は次のとおりです：

Cloudflare Tunnel
AWSプライベートリンク
Azure プライベートリンク

このような環境では、Kubernetesはパブリックなロードバランサーを一切公開しない場合があります。

TLS終端戦略

Kubernetes Readyは、特定のTLS戦略を強制しません。ご使用のプラットフォームアーキテクチャに最適なレイヤーを選択してください。

終端層	典型的な使用例
CDNまたはWAF	インターネットに接続された本番環境への展開
クラウドロードバランサー	クラウドネイティブな証明書管理
イングレスまたはゲートウェイ	プラットフォームが管理する証明書（cert-manager使用）
サービスメッシュサイドカー	エンドツーエンド暗号化されたゼロトラスト環境