K
Q

Temporary failure in name resolution redis

3/27/2020

I have been learning Kubernetes lately. And I'm trying to use redis but I am getting the following error:

Error:Error -3 connecting to redis:6379. Temporary failure in name resolution.

I'm using:

  conn = redis.StrictRedis(host='redis', port=6379)

docker composer:

     redis: 
        image: redis:alpine 
        ports:
          - "6379:6379"

redis-deploy.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-deploy
spec:
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:alpine
        ports:
        - containerPort: 6379

service redis:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: redis
  name: redis
spec:
  selector:
    app: redis
  type: NodePort
  ports:
  - port: 6379
    protocol: TCP

kubectl get svc

redis            NodePort    10.152.183.209   <none>        6379:32649/TCP   7m31s

EDIT: the image is pulling from docker, here is one of the deployment files.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: greeter-client-deploy
spec:
  replicas: 10
  selector:
    matchLabels:
      app: greeter-client
  minReadySeconds: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: greeter-client
    spec:
      containers:
      - name: greeter-client
        image: seancork92/greeter_client:latest
-- Jack
kubernetes
redis

Similar Questions

Can we increase number of pods per node in Kubernetes?
extract docker images from helm chart
Escaping '.' in helms chart yaml file
Add consul connect sidecar to pods of a kubernetes helm deployment

1 Answer

3/28/2020

What is happening is that you are exposing your Redis instance with a NodePort. Kubernetes reserves a very specific range of high-numbered network ports for NodePorts to avoid conflicting with commonly used ports like 22 or, in this case, 6379 like Redis.

When you ran kubectl get svc the service that was returned indicates that Redis is being port-forwarded to the host on port 32649. Therefore, when you perform your connection attempt against Redis you should be using this port instead of 6379. (Also ensure that your Firewall and network topology are properly configured as well).

So, where do we go from here? Well, it's hard for me to say. I am lacking information to tell both where your client connection is originating from and where your cluster is running. In the event that your client is within your cluster (AKA another Pod) you should look into provisioning a ClusterIP Service instead of a NodePort Service.

In the case where your client is external to your cluster, my advice to you is to look into how to provision LoadBalancer service types and Ingress resources in Kubernetes.

This will allow you to spin up dedicated IPs. From which you can serve your application on any port, hostname, or subdirectory without any issues. To do that, however, you will need to have both a LoadBalancer and Ingress Controller installed as the Kubernetes API Server ships with neither.

If you are using a Cloud Provider it is likely that you already have a LoadBalancer Controller. Just simply request one and then kubectl get svc and see if it ever advances from the Pending state. If you are operating on bare metal, you can use a physical load balancer like an F5 Big IP. Or you can use a Virtual Load Balancer controller like MetalLB.

Two popular Ingress Controllers are NGINX and Istio. The NGINX controller deals exclusively with ingress management while Istio deals with that as well as highly-configurable networking and enhanced security.

Let me know if you need any further information or help with this question. Always happy to help!

-- TJ Zimmerman
Source: StackOverflow