Временный сбой при повторном разрешении имени

Question

В последнее время я изучаю Kubernetes. И я пытаюсь использовать Redis, но я получаю следующую ошибку:

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

Я использую:

  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

redis службы:

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

kubectl get sv c

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

РЕДАКТИРОВАТЬ: образ извлекается из docker, вот один из файлов развертывания.

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

Answer 1

Происходит следующее: вы открываете свой экземпляр Redis с помощью NodePort . Kubernetes резервирует очень специфический c диапазон сетевых номеров с высоким номером для NodePorts, чтобы избежать конфликта с обычно используемыми портами, такими как 22 или, в данном случае, 6379, такими как Redis.

Когда вы run kubectl get svc служба, которая была возвращена, указывает, что Redis перенаправляется через порт на хост на порт 32649. Поэтому, когда вы выполняете попытку подключения к Redis, вы должны использовать этот порт вместо 6379. (Также убедитесь, что ваш брандмауэр и топология сети также правильно настроены).

Итак, где мы go отсюда? Ну, мне сложно сказать. Мне не хватает информации, чтобы сказать, откуда исходит ваше клиентское соединение и где работает ваш кластер. В случае, если ваш клиент находится в вашем кластере (AKA еще один Pod), вы должны изучить предоставление ClusterIP службы вместо службы NodePort.

В случае, когда ваш клиент является внешним по отношению к Ваш кластер, я советую вам изучить, как обеспечить LoadBalancer типов услуг и Ingress ресурсов в Kubernetes.

Это позволит вам раскрутить выделенные IP-адреса. Из которого вы можете без проблем обслуживать свое приложение на любом порту, имени хоста или подкаталоге. Для этого, однако, вам понадобится установить и LoadBalancer, и Ingress Controller , поскольку сервер Kubernetes API не поставляется ни с одним из них.

Если вы используете облачный провайдер, скорее всего, у вас уже есть контроллер LoadBalancer. Просто запросите один, а затем kubectl get svc и посмотрите, выйдет ли он когда-либо из состояния ожидания. Если вы работаете на голом металле, вы можете использовать физический балансировщик нагрузки, такой как F5 Big IP. Или вы можете использовать контроллер Virtual Load Balancer, например MetalLB .

Два популярных контроллера доступа: NGINX и Istio . Контроллер NGINX имеет дело исключительно с входным управлением, в то время как Istio занимается этим, а также настраиваемыми сетями и повышенной безопасностью.

Дайте мне знать, если вам нужна дополнительная информация или помощь по этому вопросу. Всегда рады помочь!