У меня ситуация, когда Kubernetes, по-видимому, больше не может назначать внешний IP-адрес службе после kubectl create -f Deployment. yaml
. kubectl description service
сообщает о следующей ошибке :
CreatingLoadBalancerFailed
Error creating load balancer (will retry): Failed to create load balancer
for service default/<my-service>: requested ip <my-address> is
neither static nor assigned to LB <id>(default/<my-service>): <nil>
Но список адресов вычислений gcloud
указывает, что my-address
- статический IP-адрес:
NAME REGION ADDRESS STATUS
<my-address> europe-west1 <ip-address> RESERVED
И Deployment.yaml
содержит спецификацию для
, которая назначает
загрузке balancer:
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: UDP
port: <my-port>
type: LoadBalancer
loadBalancerIP: <my-address>
Что особенно странно: (почти) такое же развертывание работало и раньше. Я уже пытался воссоздать свой кластер, но это тоже не помогло. Что еще может быть не так и как я могу преодолеть ошибку, чтобы снова сделать мою службу доступной извне?
ОБНОВЛЕНИЕ Я зарезервировал новый статический (на этот раз также глобальный) IP-адрес с вычислительными адресами gcloud создайте тестовый адрес --global
и соответствующим образом измените назначение LB: loadBalancerIP: test-address
. Но та же ошибка остается.
ОБНОВЛЕНИЕ Если я не укажу loadBalancerIP
в Deployment.yaml
, развертывание пройдет без ошибок, и будет назначен новый внешний IP-адрес на my-service
. Служба может быть отправлена извне по этому адресу.
ОБНОВЛЕНИЕ Если я удалю свой прежний адрес с помощью вычислений адресов gcloud, удалите мой адрес --region europe-west1
, продвигайте новый внешний адрес с помощью gcloud compute address create --addresses
, а затем повторно разверните с исходной строкой loadBalancerIP: my-address
восстановлено в Deployment.yaml
снова появляется та же ошибка.
Проблема была в Deployment.yaml
, где я имел в виду адрес в loadBalancerIp
по его символическому имени, а не по числовому IP-адресу ([ ИМЯ
и АДРЕС
, как показано списком адресов вычислений gcloud
соответственно). Если вместо этого я использую числовой IP-адрес, появляется подсистема балансировки нагрузки, к которой можно получить доступ извне по этому адресу (через подсистему балансировки нагрузки). ( Этот предыдущий ответ привел меня на правильный путь. У меня сложилось, возможно, неправильное впечатление, что использование символического имени ранее работало.)
Справочная информация Поскольку я переключался ] в собственный экземпляр виртуальной машины (вместо оболочки Google Cloud) для разработки образов контейнеров, я получаю «Недостаточное разрешение»
ошибки из списка адресов вычислений gcloud
на этом экземпляре виртуальной машины. Я понимаю, что могу улучшить это, воссоздав экземпляр виртуальной машины с областью действия https://www.googleapis.com/auth/compute.readonly
. В любом случае, это ограничение явно не имело отношения к рассматриваемой проблеме.
У меня была аналогичная проблема. Оказывается, если IP-адрес зарезервирован как глобальный, он не сработает. Я удалил свое бронирование и изменил его на тот же регион, что и мой кластер кубернетов. - global
Мне пришлось использовать - region europe-west2
- тот же регион, что и мой кластер k8s.
before: fail
адреса вычислений gcloud создают my-secure -sftp --global
after: success
адреса вычислений gcloud создают my-secure-sftp --region europe-west2
@see https://github.com/kubernetes/kubernetes/issues / 22721 подробнее
Вы должны создать региональный адрес:
gcloud compute address create my-secure-sftp --region europe-west2
Он выделяет глобальный IP-адрес для входящего контроллера (статус IN_USE), это именно то, что вам нужно.
Global static и Internal static не будут работать в вашем случае.