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

<pre><code>Error:Error -3 connecting to redis:6379. Temporary failure in name resolution.
</code></pre>

<p>I'm using:</p>

<pre><code>  conn = redis.StrictRedis(host='redis', port=6379)
</code></pre>

<p><strong>docker composer</strong>:</p>

<pre><code>     redis: 
        image: redis:alpine 
        ports:
          - "6379:6379" 
</code></pre>

<p><strong>redis-deploy.yml</strong></p>

<pre><code>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
</code></pre>

<p><strong>service redis:</strong></p>

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

<p><strong>kubectl get svc</strong></p>

<pre><code>redis            NodePort    10.152.183.209   &lt;none&gt;        6379:32649/TCP   7m31s
</code></pre>

<p><strong>EDIT:</strong> the image is pulling from docker, here is one of the deployment files.</p>

<pre><code>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
</code></pre>

Jack
<p>What is happening is that you are exposing your Redis instance with a <a href="https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types" rel="nofollow noreferrer">NodePort</a>. Kubernetes reserves a very specific range of <a href="https://kubernetes.io/docs/concepts/services-networking/service/#nodeport" rel="nofollow noreferrer">high-numbered</a> network ports for NodePorts to avoid conflicting with commonly used ports like 22 or, in this case, 6379 like Redis.</p>

<p>When you ran <code>kubectl get svc</code> the service that was returned indicates that Redis is being <a href="https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/#exposing-the-service" rel="nofollow noreferrer">port-forwarded</a> to the host on port <code>32649</code>. 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).</p>

<p>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 <a href="https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types" rel="nofollow noreferrer">ClusterIP</a> Service instead of a NodePort Service.</p>

<p>In the case where your client is external to your cluster, my advice to you is to look into how to provision <a href="https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer" rel="nofollow noreferrer">LoadBalancer</a> service types and <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" rel="nofollow noreferrer">Ingress</a> resources in Kubernetes. </p>

<p>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 <a href="https://kubernetes.io/docs/concepts/architecture/controller/" rel="nofollow noreferrer">Controller</a> installed as the Kubernetes API Server ships with neither. </p>

<p>If you are using a Cloud Provider it is likely that you already have a LoadBalancer Controller. Just simply request one and then <code>kubectl get svc</code> 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 <a href="https://metallb.universe.tf/" rel="nofollow noreferrer">MetalLB</a>. </p>

<p>Two popular Ingress Controllers are <a href="https://www.google.com/search?q=nginx-ingress&amp;oq=nginx-ingress&amp;aqs=chrome.0.69i59j0l6j69i65.1552j0j4&amp;sourceid=chrome&amp;ie=UTF-8" rel="nofollow noreferrer">NGINX</a> and <a href="https://istio.io/faq/" rel="nofollow noreferrer">Istio</a>. The NGINX controller deals exclusively with ingress management while Istio deals with that as well as highly-configurable networking and enhanced security. </p>

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