# #kubernetes #google-cloud-platform #google-kubernetes-engine
Вопрос:
Я пытаюсь развернуть node.js приложение (настроенное в реестре артефактов) в кластер GCP Kubernetes… а затем также поместите службу / развертывание за вход, чтобы наш статический интерфейс мог взаимодействовать с этим приложением через CORS.
Я могу заставить службу работать без использования ingress (просто стандартная служба / развертывание), но интерфейс не может с ней взаимодействовать из-за ошибок CORS. После исследования я узнал, что я должен создать вход для управления трафиком для этого сценария.
Я проверил, что приложение запущено, просмотрев журналы рабочих нагрузок GKE (приложение запущено), а также введя модули GKE (через busybox curl proxy), и я могу свернуть службу GKE, и она возвращает ожидаемые ответы. Итак, я определил, что проблема связана с тем, что трафик балансировщика нагрузки маршрутизируется неправильно или по какой-то причине отклоняется. 
Развертывание приложения настроено для запуска на порту 80 везде (как в Docker / app, так и в node port / targetPort).
Я включил брандмауэры как для самого порта узла, так и для проверок работоспособности, как описано в документации GCP: 
Шаги, которые я в основном выполнил, следующие:
- Создайте новый кластер GKE (с включенной балансировкой нагрузки HTTP, хотя я не уверен, что это необходимо, поскольку приведенное ниже определение входа автоматически создает собственный балансировщик нагрузки)
- Затем я применил эту конфигурацию deployment service ingress с помощью:
kubectl apply -f deployment.yaml:
# Main api deployment
kind: Deployment
apiVersion: apps/v1
metadata:
name: adcloud-api
spec:
selector:
matchLabels:
app: adcloud-api
replicas: 1
template:
metadata:
labels:
app: adcloud-api
spec:
containers:
- name: adcloud-api
image: gcr.io/ad-cloud-328718/adcloud/adcloud-web-api-image:v1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
protocol: TCP
resources:
requests:
memory: "32Mi"
cpu: "100m"
limits:
memory: "128Mi"
cpu: "250m"
---
# Service for the above deployment
kind: Service
apiVersion: v1
metadata:
name: adcloud-api
annotations:
cloud.google.com/backend-config: '{"ports": {"80":"adcloud-api-backendconfig"}, "default": "adcloud-api-backendconfig"}'
spec:
#3type: LoadBalancer
type: NodePort
selector:
app: adcloud-api
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 32001
---
kind: BackendConfig
apiVersion: cloud.google.com/v1
metadata:
name: adcloud-api-backendconfig
spec:
healthCheck:
# timeoutSec: 10
# checkIntervalSec: 30
requestPath: /health
port: 80
type: HTTP
---
# Ingress for the above service
kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
name: api-ingress
annotations:
kubernetes.io/ingress.class: "gce"
gce.ingress.kubernetes.io/enable-cors: "true"
gce.ingress.kubernetes.io/cors-allow-credentials: "true"
gce.ingress.kubernetes.io/cors-allow-methods: "GET, POST, PUT, PATCH, DELETE, OPTIONS"
gce.ingress.kubernetes.io/cors-allow-origin: "*"
spec:
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: adcloud-api
port:
number: 80
У меня есть общая проверка работоспособности, определенная на порту 80:
Внутренние службы, определенные для созданного балансировщика нагрузки, показывают 1 работоспособный и 1 другой неработоспособный, поскольку проверки работоспособности для него «истекли». 
Вы можете видеть, что эта внутренняя служба нацелена на порт узла 32001. Правильно ли это? У меня есть файл Dockerfile приложения, предоставляющий только порт 80, и порт 80 определен везде (т. Е. в проверках работоспособности). Должна ли серверная служба здесь также использовать порт 80 или она должна использовать порт узла 32001? Есть ли какой-то внутренний прокси-сервер, обрабатывающий это?
Члены группы экземпляров в группе экземпляров для этого «нездорового» сервера балансировки нагрузки показывают, что «ресурс не существует» для экземпляров виртуальной машины…
Однако экземпляры виртуальной машины GCE показывают, что эти экземпляры существуют? 
kubectl описывает вход:
$ kubectl describe ingress
Name: api-ingress
Namespace: default
Address: 35.227.241.142
Default backend: default-http-backend:80 (10.0.17.5:8080)
Rules:
Host Path Backends
---- ---- --------
*
/* adcloud-api:80 (10.0.17.6:80)
Annotations: gce.ingress.kubernetes.io/cors-allow-credentials: true
gce.ingress.kubernetes.io/cors-allow-methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
gce.ingress.kubernetes.io/cors-allow-origin: *
gce.ingress.kubernetes.io/enable-cors: true
ingress.kubernetes.io/backends: {"k8s-be-32001--8950a5f3e6292d2e":"Unknown","k8s-be-32722--8950a5f3e6292d2e":"Unknown"}
ingress.kubernetes.io/forwarding-rule: k8s2-fr-nto0o9ht-default-api-ingress-vo6louo7
ingress.kubernetes.io/target-proxy: k8s2-tp-nto0o9ht-default-api-ingress-vo6louo7
ingress.kubernetes.io/url-map: k8s2-um-nto0o9ht-default-api-ingress-vo6louo7
kubernetes.io/ingress.class: gce
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Sync 35m loadbalancer-controller UrlMap "k8s2-um-nto0o9ht-default-api-ingress-vo6louo7" created
Normal Sync 35m loadbalancer-controller TargetProxy "k8s2-tp-nto0o9ht-default-api-ingress-vo6louo7" created
Normal Sync 34m loadbalancer-controller ForwardingRule "k8s2-fr-nto0o9ht-default-api-ingress-vo6louo7" created
Normal IPChanged 34m loadbalancer-controller IP is now 35.227.241.142
Normal Sync 12m (x5 over 35m) loadbalancer-controller Scheduled for sync
kubectl описывает модули:
$ kubectl describe pods
Name: adcloud-api-5cb96bb47d-tmrd8
Namespace: default
Priority: 0
Node: gke-adcloud-cluster-default-pool-6f91d4e7-z7ks/10.128.15.216
Start Time: Wed, 27 Oct 2021 00:51:50 -0400
Labels: app=adcloud-api
pod-template-hash=5cb96bb47d
Annotations: <none>
Status: Running
IP: 10.0.17.6
IPs:
IP: 10.0.17.6
Controlled By: ReplicaSet/adcloud-api-5cb96bb47d
Containers:
adcloud-api:
Container ID: containerd://ebd1b857c541b8fdc52dcc6e44d4617d9558bd7e16783a5a016d5bdd1cce7370
Image: gcr.io/ad-cloud-328718/adcloud/adcloud-web-api-image:v1
Image ID: gcr.io/ad-cloud-328718/adcloud/adcloud-web-api-image@sha256:932e59850992e37854242cac9e70ca65eb52863f63c795d892c84671dca4ba68
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Wed, 27 Oct 2021 02:19:48 -0400
Ready: True
Restart Count: 0
Limits:
cpu: 250m
memory: 128Mi
Requests:
cpu: 100m
memory: 32Mi
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-4xcjx (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-4xcjx:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-4xcjx
Optional: false
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedMount 53m kubelet MountVolume.SetUp failed for volume "default-token-4xcjx" : failed to sync secret cache: timed out waiting for the condition
Normal Pulling 53m kubelet Pulling image "gcr.io/ad-cloud-328718/adcloud/adcloud-web-api-image:v1"
Normal Pulled 52m kubelet Successfully pulled image "gcr.io/ad-cloud-328718/adcloud/adcloud-web-api-image:v1" in 52.167675207s
Normal Created 52m kubelet Created container adcloud-api
Normal Started 52m kubelet Started container adcloud-api
Normal Pulling 34m kubelet Pulling image "gcr.io/ad-cloud-328718/adcloud/adcloud-web-api-image:v1"
Normal Pulled 34m kubelet Successfully pulled image "gcr.io/ad-cloud-328718/adcloud/adcloud-web-api-image:v1" in 29.499249423s
Normal Started 34m kubelet Started container adcloud-api
Normal Created 34m kubelet Created container adcloud-api
Warning NodeNotReady 16m (x7 over 95m) node-controller Node is not ready
Normal Pulling 14m kubelet Pulling image "gcr.io/ad-cloud-328718/adcloud/adcloud-web-api-image:v1"
Normal Pulled 13m kubelet Successfully pulled image "gcr.io/ad-cloud-328718/adcloud/adcloud-web-api-image:v1" in 27.814932495s
Normal Created 13m kubelet Created container adcloud-api
Normal Started 13m kubelet Started container adcloud-api
Я действительно не знаю, что мешает нездоровой природе единой внутренней службы, почему к ней нельзя получить доступ для проверки работоспособности.
Вы можете видеть, что вход не может видеть внутренние службы здесь: 
Они недоступны, потому что проверка работоспособности завершается неудачно, или проверка работоспособности завершается неудачно, потому что они недоступны? У кого-нибудь есть какие-либо предложения о том, что еще может здесь происходить? Нужно ли мне выполнять какие-либо сетевые настройки, помимо приведенного выше файла определения развертывания? Должны ли проверки работоспособности выполняться на открытых портах приложений (т.Е. 80) или на эфемерном узловом порту (т.е. 32001)?
Входящий внешний IP-адрес приводит к 502 из-за недоступности серверной части: 
Я занимаюсь этим уже несколько дней и был бы признателен за любую помощь на этом этапе!
Комментарии:
1. Вы пробовали раскомментировать timeoutSec и checkIntervalSec ? Кроме того, попробуйте изменить свой targetPort на 8080.
2. Спасибо. Если я изменю targetPorrt на 8080, это будет означать, что мне нужно будет убедиться, что мое приложение запускается на порту 8080, правильно? В настоящее время все настроено для порта 80. Почему изменение на 8080 может что-то изменить? Я попробую.
Ответ №1:
Обычно используется другой порт и порт назначения. Взгляните на примеры служб в документации.
Я также заметил, что вы прокомментировали Loadbalancer и изменили тип службы на NodePort . Убедитесь, что настройки во всех файлах yaml выровнены.
Если все настройки верны, а проблема сохраняется, включите ведение журнала GKE и обратитесь в службу поддержки Google или сообщите о проблеме через общедоступный трекер проблем.
Комментарии:
1. K, спасибо, попробую все это.