何が起こっているのかというと、NodePortを使用してRedisインスタンスを公開しているということです。 Kubernetesは、22のような一般的に使用されるポート、この場合はRedisのような6379との競合を回避するために、NodePort用に非常に特定の範囲の多数のネットワークポートを予約しています。
kubectl get svcを実行すると 返されたサービスは、Redisがポート32649でホストにポート転送されていることを示しています 。したがって、Redisに対して接続を試行するときは、6379ではなくこのポートを使用する必要があります（ファイアウォールとネットワークトポロジも適切に構成されていることも確認してください）。
では、ここからどこへ行くのでしょうか。ええと、私には言い難いです。クライアント接続の発信元とクラスターの実行場所の両方を示す情報が不足しています。クライアントがクラスター（別名別のポッド）内にある場合は、NodePortサービスではなくClusterIPサービスのプロビジョニングを検討する必要があります。
クライアントがクラスターの外部にある場合、KubernetesでLoadBalancerサービスタイプとIngressリソースをプロビジョニングする方法を調べることをお勧めします。
これにより、専用IPを起動できます。そこから、問題なく、任意のポート、ホスト名、またはサブディレクトリでアプリケーションを提供できます。ただし、これを行うには、Kubernetes APIサーバーに両方が付属しているため、LoadBalancerとIngressControllerの両方をインストールする必要があります。
クラウドプロバイダーを使用している場合は、すでにLoadBalancerコントローラーを使用している可能性があります。リクエストするだけで、kubectl get svc 保留状態から進行するかどうかを確認します。ベアメタルで操作している場合は、F5BigIPのような物理的なロードバランサーを使用できます。または、MetalLBなどの仮想ロードバランサーコントローラーを使用できます。
2つの人気のあるIngressControllerは、NGINXとIstioです。 NGINXコントローラーは、入力管理のみを処理しますが、Istioは、高度に構成可能なネットワーキングと強化されたセキュリティだけでなく、入力管理も処理します。
さらに詳しい情報が必要な場合、またはこの質問についてサポートが必要な場合は、お知らせください。いつでも喜んでお手伝いします！