Не удалось запустить пробную виртуальную машину dA Platform

Попробуйте запустить kubectl get deployment daplatform-appmanager, чтобы проверить, работает ли он в данный момент. К сожалению, запуск может занять некоторое время, поскольку существует множество зависимых служб. Если kubectl не показывает доступных экземпляров, попробуйте перечислить модули с помощью kubectl get pods и найти тот, который называется daplatform-appmanager-... и находится в состоянии CrashLoopBackOff. Мы хотим проверить журналы, чтобы узнать, почему он не работает, что вы можете сделать с помощью kubectl logs <pod-name-here>.

Как недавно вы загрузили виртуальную машину? Если он у вас уже был некоторое время, возможно, срок действия пробной лицензии, поставляемой с виртуальной машиной, уже истек. В этом случае вам нужно будет загрузить новую копию виртуальной машины, чтобы продолжить ее использование.

Скачал 07.08.2018, буквально два дня назад.

Привет. Я просто снова запускаю виртуальную машину, теперь все в порядке, может быть, как вы сказали, «запуск может занять довольно много времени, поскольку существует множество зависимых служб».

Спасибо за информацию. TWW, при использовании платформы dA работает только один диспетчер заданий, и даже нет необходимости устанавливать кластер Zookeeper для достижения высокой доступности, верно? Как Kubernetes обеспечит высокую доступность единого менеджера заданий?

Эй, да, на каждое задание Flink выполняется только один JM. Однако на виртуальной машине JobManager HA по умолчанию не включен. Zookeeper в настоящее время не является частью платформы dA. Для достижения HA нужно настроить ZK, настроить его с помощью кластера Flink. Затем Kubernetes перезапустит неисправные менеджеры заданий, а ZK будет использоваться для сохранения состояния JM для восстановления.

Если состояние JM можно сохранить в HDFS ,? Значит, нам не нужно полагаться на Zookeeper?

Эй, у вас должен быть ZK, чтобы использовать JM HA. ZK используется для выбора лидера и для хранения метаданных восстановления.

Я имею в виду использование Kubernetes с одним JM, поскольку Kubernetes обеспечивает доступность JM, поэтому нет необходимости снова использовать ZK для выборов лидера, верно? В этом случае, если мы можем сохранить метаданные в HDFS, тогда, когда обнаружение Kubernetes обнаружит отказавший JM, он может перезапустить другой зеркальный JM, тогда новый JM получит метаданные из HDFS, поэтому ZK не требуется, это имеет смысл ?

Вы правы, что это могло сработать. Однако на данный момент для платформы dA требуется Zookeeper. Нам известно об этом ограничении, и мы планируем устранить его в следующем выпуске dAP (версия 1.3), который запланирован на конец этого года.