Von Kubernetes gehostete Clientanwendung

Clientverbindungen von mehreren Pods

Wenn von mehreren Pods eine Verbindung mit einem Redis-Server hergestellt wird, stellen Sie sicher, dass die neuen Verbindungen von den Pods gestaffelt erstellt werden. Wenn innerhalb kurzer Zeit mehrere Pods gleichzeitig gestartet werden, führt dies zu einer plötzlichen Spitze in der Anzahl erstellter Clientverbindungen. Die hohe Anzahl von Verbindungen führt zu einer hohen Belastung des Redis-Servers und kann Timeouts verursachen.

Vermeiden Sie dasselbe Szenario, das durch gleichzeitiges Herunterfahren mehrerer Pods entsteht. Wenn das Herunterfahren nicht gestaffelt wird, kann dies zu einem erheblichen Abfall der Anzahl von Verbindungen und somit zur CPU-Auslastung führen.

Ausreichende Podressourcen

Stellen Sie sicher, dass dem Pod, auf dem Ihre Clientanwendung ausgeführt wird, genügend CPU- und Arbeitsspeicherressourcen zur Verfügung stehen. Wenn die Clientanwendung bis an die Grenzen ihrer Ressourcen ausgeführt wird, kann dies zu Timeouts führen.

Ausreichende Knotenressourcen

Ein Pod, auf dem die Clientanwendung ausgeführt wird, kann von anderen auf demselben Knoten ausgeführten Pods beeinträchtigt werden. Dies kann zur Drosselung von Redis-Verbindungen oder E/A-Vorgänge führen. Stellen Sie daher immer sicher, dass der Knoten, auf dem Ihre Clientanwendungspods ausgeführt werden, über genügend Arbeitsspeicher- und CPU-Ressourcen sowie Netzwerkbandbreite verfügen. Wenn eine dieser Ressourcen nicht verfügbar ist, kann dies zu Konnektivitätsproblemen führen.

Unter Linux gehostete Clientanwendungen und TCP-Einstellungen

Wenn Ihre Azure Cache for Redis-Clientanwendung in einem Linux-basierten Container ausgeführt wird, empfiehlt es sich, einige TCP-Einstellungen zu aktualisieren. Diese Einstellungen werden unter TCP-Einstellungen für unter Linux gehostete Clientanwendungen ausführlicher erläutert.

Potenzieller Verbindungskonflikt mit Istio/Envoy

Derzeit verwendet Azure Cache for Redis die Ports 15000 bis 15019 für gruppierte Caches, um Clusterknoten für Clientanwendungen verfügbar zu machen. Wie hier dokumentiert, werden die gleichen Ports auch vom Istio.io-Sidecar-Proxy namens Envoy verwendet. Daher kann es zu Konflikten beim Erstellen von Verbindungen kommen (insbesondere bei Port 15006).

Zur Vermeidung von Verbindungskonflikten wird Folgendes empfohlen:

  • Verwenden Sie stattdessen ggf. einen nicht gruppierten Cache.
  • Konfigurieren Sie keine Istio-Sidecars in Pods, die Azure Cache for Redis-Clientcode ausführen.

Nächste Schritte