skip to Main Content

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

2

Answers


  1. 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!

    Login or Signup to reply.
  2. I used the yaml file below for redis (that I got and modified a bit from How to deploy a node.js with redis on kubernetes?):

    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: redis
      name: redis
    spec:
      externalIPs:
      - 192.168.2.146
      selector:
        app: redis
      type: NodePort
      ports:
      - port: 6379
        nodePort: 32000
        protocol: TCP
        targetPort: 6379
    ---
    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:latest
            ports:
            - containerPort: 6379
            volumeMounts:
            - name: data
              mountPath: /data
              readOnly: false
          volumes:
          - name: data
            persistentVolumeClaim:
              claimName: redis-data          
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: redis-data
      labels:
        app: redis
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Mi
    

    After deploying with the yaml file, when you run microk8s.kubectl get services, you should a response like below:

    NAME         TYPE        CLUSTER-IP       EXTERNAL-IP    PORT(S)          AGE
    kubernetes   ClusterIP   10.152.183.1     <none>         443/TCP          14d
    redis        NodePort    10.152.183.114   192.168.2.146   6379:32000/TCP   14m
    

    In my case, microk8s is deployed on a local VM that is on 192.168.2.146 (which is described in externalIPs. So with this setup I could access redis from both the local VM (CentOS) and from the parent machine (Windows). Also, if microk8s is deployed on a remote server like in my case, you also need to open port 6379 so your code can access it remotely. To test the connectivity from the VM I used the commands below:

    echo PING | nc 192.168.2.146 6379
    echo PING | nc localhost 32000
    

    For both commands you should get the response:

    +PONG
    

    From Windows you can use PowerShell and use the command tnc 192.168.2.146 -port 6379 to test connectivity. You should get a response like below:

    ComputerName     : 192.168.2.146
    RemoteAddress    : 192.168.2.146
    RemotePort       : 6379
    InterfaceAlias   : <alias>
    SourceAddress    : <source_ip>
    TcpTestSucceeded : True
    
    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search