标签: kubernetes-ingress

我使用了一些反向代理，例如 HAProxy、Traefik 和 Kong。当我开始使用 Kubernetes 时，我对 Ingress 的概念感到困惑。后端资源的路由不是也可以通过反向代理实现吗？使用 Ingress 的目的是什么？

我想在 Google Kubernetes Engine 中部署许多 Pod，然后通过子域（如 pod-name-or-label.mydomain.com）或路径路由（如 protocol://mydomain.com:7878/pod-）建立到每个特定 Pod 的 TCP 连接名称或标签。

我研究过不同的方向，例如 Istio 或 nginx-ingress，但在我看来这太复杂了。

难道没有一个简单的解决方案吗？

我在 kubernetes 上部署了 Vue JS。我需要像这个页面一样配置 nginx 路由：

https://router.vuejs.org/guide/essentials/history-mode.html#example-server-configurations

配置是这样的：

location / {
  try_files $uri $uri/ /index.html;
} 

如何将该配置转换为 ingress kubernetes yaml 配置？

我尝试过这个但不起作用

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /index.html
  name: backoffice
  namespace: default
  selfLink: /apis/extensions/v1beta1/namespaces/default/ingresses/backoffice
spec:
  rules:
    - host: dev.abc.com
      http:
        paths:
          - backend:
              serviceName: backoffice-svc
              servicePort: 443
            path: /

我尝试使用这个注释，但仍然不起作用：

nginx.ingress.kubernetes.io/app-root: /app1

对于部署在 Google kubernetes 引擎上的基于微服务的架构示例，我需要帮助来验证我的理解：

1. 我们知道服务应该对 Pod 副本集的流量进行负载平衡。
2. 当我们创建 nginx 入口控制器和入口定义以路由到每个服务时，还会自动设置负载均衡器。
3. 在某处读到，创建 nginx 入口控制器意味着在幕后创建 nginx 控制器（部署）和负载均衡器类型服务。我不确定这是否属实。

看来负载平衡是由服务完成的。基于 URL 的路由由入口控制器完成。

为什么我们需要负载均衡器？它并不意味着跨多个实例进行负载平衡。它只会将所有流量转发到创建的 nginx 反向代理，并根据 URL 路由请求。

如果我的理解有误，请指正。

我对使用 Helm Chart 非常陌生，不知道为什么在尝试安装 Helm Chart 时会出现此错误。我正在使用 --set 和 helm install 命令来设置 ingress.hosts[0].host 处的主机名。我不明白为什么它说缺少路径，而“路径”已经存在。

入口.yaml

{{- if .Values.ingress.enabled -}}
{{- $fullName := include "project.fullname" . -}}
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: {{ $fullName }}
  labels:
    app.kubernetes.io/name: {{ include "project.name" . }}
    helm.sh/chart: {{ include "project.chart" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
  {{- with .Values.ingress.annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
  {{- end }}
spec:
{{- if .Values.ingress.tls }}
  tls:
  {{- range .Values.ingress.tls …

我有多个 Pod，可以自动扩展和缩小。

我使用入口作为入口点。我需要根据某些条件（比如说路径）将外部流量路由到特定的 Pod。在发出请求时，我确定特定的 Pod 已启动。

例如，假设我有域 someTest.com，通常将流量路由到 pod 1、2 和 3（假设我通过内部 ip - 192.168.1.10、192.168.1.11 和 192.168.1.13 来识别它们）。

当我调用 someTest.com/specialRequest/12 时，我需要将流量路由到 192.168.1.12，当我调用 someTest.com/specialRequest/13 时，我想将流量路由到 192.168.1.13。对于正常情况（someTest.com/normalRequest），我只想正常地完成他的史诗般的工作。

如果 pod 扩大并出现 192.168.1.14，我需要能够调用 someTest.com/specialRequest/14 并路由到提到的 pod。

无论如何我可以实现这个目标吗？

我已经部署了AWS elb和nginx-controller。我正在使用 nginx 将流量路由到不同的命名空间。当我应用入口资源并描述它时，我得到：

----    ------  ----               ----                      -------
  Normal  Sync    42m (x4 over 72m)  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    42m (x4 over 72m)  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    42m (x4 over 72m)  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    42m (x4 over 72m)  nginx-ingress-controller  Scheduled for sync

我无法联系到主机，但它与其他主机运行良好。

kubectl describe ing XXXXX

Name:             promethues-ingress-dev
Namespace:        monitoring
Address:          172.20.223.123
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
  Host                     Path  Backends
  ----                     ----  --------
  dashboard.dev.xxxx.ai
                           /*   kube-prom-stack-dev-grafana:80 (10.0.1.189:3000)
Annotations: …

我有一个 API 最近开始接收更多流量，大约是 1.5 倍。这也导致延迟加倍：

这让我感到惊讶，因为我设置了节点和 Pod 的自动缩放以及 GKE 内部负载平衡。

我的外部 API 将请求传递到使用大量 CPU 的内部服务器。查看我的 VM 实例，似乎所有流量都发送到我的两个 VM 实例之一（也称为 Kubernetes 节点）：

通过负载平衡，我预计 CPU 使用率会在节点之间更加均匀地分配。

查看我的部署，第一个节点上有一个 pod：

第二个节点上有两个 pod：

我的服务配置：

$ kubectl describe service model-service
Name:                     model-service
Namespace:                default
Labels:                   app=model-server
Annotations:              networking.gke.io/load-balancer-type: Internal
Selector:                 app=model-server
Type:                     LoadBalancer
IP Families:              <none>
IP:                       10.3.249.180
IPs:                      10.3.249.180
LoadBalancer Ingress:     10.128.0.18
Port:                     rest-api  8501/TCP
TargetPort:               8501/TCP
NodePort:                 rest-api  30406/TCP
Endpoints:                10.0.0.145:8501,10.0.0.152:8501,10.0.1.135:8501
Port:                     grpc-api  8500/TCP
TargetPort:               8500/TCP
NodePort:                 grpc-api  31336/TCP
Endpoints:                10.0.0.145:8500,10.0.0.152:8500,10.0.1.135:8500
Session Affinity:         None …

不确定这是否特定于操作系统，但在我的 M1 Mac 上，我正在安装 Nginx 控制器和控制器官方快速入门指南中的资源示例。适用于 Mac 的 Docker 桌面。说明如下：

// Create the Ingress
helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace

// Pre-flight checks
kubectl get pods --namespace=ingress-nginx

kubectl wait --namespace ingress-nginx \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/component=controller \
  --timeout=120s

// and finally, deploy and test the resource.
kubectl create deployment demo --image=httpd --port=80
kubectl expose deployment demo

kubectl create ingress demo-localhost --class=nginx \
  --rule=demo.localdev.me/*=demo:80

kubectl port-forward --namespace=ingress-nginx service/ingress-nginx-controller 8080:80

我注意到说明没有提到必须编辑文件/etc/hosts，我觉得这很奇怪。而且，当我将其放入demo.localdev.me:8080 …

我正在尝试将某些 GKE 集群从 1.21 升级到 1.22，但收到一些有关已弃用 API 的警告。我的集群中也运行 Istio 1.12.1 版本

其中之一引起了我的一些担忧：

/apis/extensions/v1beta1/ingresses

我很惊讶地看到这个警告，因为我们的部署是最新的。我们不使用 Ingress。

进一步深入研究，我得到了以下详细信息：

\xe2\x9e\x9c kubectl get --raw /apis/extensions/v1beta1/ingresses | jq\nWarning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress\n{\n  "kind": "IngressList",\n  "apiVersion": "extensions/v1beta1",\n  "metadata": {\n    "resourceVersion": "191638911"\n  },\n  "items": []\n}\n

看来 IngressList 是调用旧 API 的。尝试删除相同的，

\xe2\x9e\x9c  kubectl delete --raw /apis/extensions/v1beta1/ingresses\nError from server (MethodNotAllowed): the server does not allow this method on the requested resource\n

既不能删除，也不能升级。