Не удалось подключиться к кластеру Akka с помощью kubernetes-api discovery - PullRequest
Новая
       25

Не удалось подключиться к кластеру Akka с помощью kubernetes-api discovery

0 голосов
/ 25 октября 2019

Я проявил должную осмотрительность, даже копаясь в коде Akka, но не могу понять, почему мои узлы обнаруживаются с помощью kubernetes-api, один узел самостоятельно присоединяется, продвигается к лидеру, а другой не может присоединитьсякластер из-за неспособности лидера разрешить адрес запрашивающего. Я опубликую конфигурацию приложения и журналы отдельно.

Это кластер Akka с двумя узлами, использующий Akka Management и Akka Discovery, использующий kubernetes-api для обнаружения узлов в 2 модулях. Я использую пользовательский селектор меток «application = vcsvc, environment = multibox, akka-cluster = vcsvc».

Может кто-нибудь помочь определить, где я неправильно сконфигурировал вещи?

Фрагмент изapplication.conf: 

akka: {
  management: {
    cluster: {
      bootstrap: {
        # optionally prohibits creating a new cluster, forcing a member to wait until cluster is formed
        new-cluster-enabled: on

        contact-point-discovery: {
          # pick the discovery method you'd like to use:
          discovery-method: "kubernetes-api"

          # the exact number of nodes for the initial startup of the cluster
          required-contact-point-nr: 2
        }
      }

      health-check: {
        # Ready health check returns 200 when cluster membership is in the following states.
        # Intended to be used to indicate this node is ready for user traffic so Up/WeaklyUp
        # Valid values: "Joining", "WeaklyUp", "Up", "Leaving", "Exiting", "Down", "Removed"
        ready-states: ["Up", "WeaklyUp"]

        readiness-path: "health/ready"
        liveness-path: "health/alive"
      }
    }
  }

  discovery: {
    # Set the following in your application.conf if you want to use this discovery mechanism:
    method: kubernetes-api

    kubernetes-api: {
      class = akka.discovery.kubernetes.KubernetesApiServiceDiscovery

      # API server, cert and token information. Currently these are present on K8s versions: 1.6, 1.7, 1.8, and perhaps more
      api-ca-path = "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
      api-token-path = "/var/run/secrets/kubernetes.io/serviceaccount/token"
      api-service-host-env-name = "KUBERNETES_SERVICE_HOST"
      api-service-port-env-name = "KUBERNETES_SERVICE_PORT"

      # Namespace to query for pods.
      #
      # Set this value to a specific string to override discovering the namespace using pod-namespace-path.
      pod-namespace = ${com.apptio.vcsvc.namespace}

      # Selector value to query pod API with.
      # `%s` will be replaced with the configured effective name, which defaults to the actor system name
      pod-label-selector: "application="${com.apptio.vcsvc.namespace}",environment="${com.apptio.vcsvc.environment}",akka-cluster="${com.apptio.vcsvc.cluster.name}
    }
  }
}

Я добавлю больше по запросу. Я подвергаю сомнению строку метода и аппликации, поскольку поведение не изменилось, когда я добавил их.

1 Ответ

0 голосов
/ 28 октября 2019

Итак, получается, что причина, по которой второй узел не смог ответить на событие успешного соединения (мы видели, что это происходит в журналах), была связана с проблемой конфигурации akka.remote. Этот не был очевиден для нас из-за всей документации и примера кода Lightbend's / Akka, предписывающего нам использовать akka.remote.artery. По причинам, которые я еще не определил, это работает в локальной ситуации Discovery, но не в нашей среде K8. Скорее там мне нужно было использовать akka.remote.netty.tcp. Я приведу полную конфигурацию для ясности ниже.

Сбой: 

akka: {
  remote: {
    artery: {
      enabled: on
      transport: tcp
      canonical.port: 2552
    }
  }
}

Работа: 

akka: {
  remote: {
    netty.tcp: {
      hostname:  ${HOSTNAME}
      port: 2552
    }
  }
}

Надеюсь, что это поможет кому-то еще избежать полторы неделипотерянной производительности когда-нибудь.

...