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 15xxx 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 15001 und 15006.
Wenn Sie Istio mit einem Azure-Cache für Redis-Cluster verwenden, sollten Sie die potenziellen Kollisionsports mit einer istio Anmerkungausschließen.
annotations:
traffic.sidecar.istio.io/excludeOutboundPorts: "15000,15001,15004,15006,15008,15009,15020"
Zur Vermeidung von Verbindungskonflikten wird Folgendes empfohlen:
- Erwägen Sie stattdessen die Verwendung eines Cache ohne Cluster oder eines Cache auf Enterprise-Ebene
- Konfigurieren Sie keine Istio-Sidecars in Pods, die Azure Cache for Redis-Clientcode ausführen.