标签: kubernetes-ingress

所以我将 Kubernetes 用于一个副项目，它很棒。为我所从事的小型项目运行更便宜（3-5 个实例的小集群基本上可以在 GCP 上以大约 30 美元/月的价格提供我所需的一切）。

我唯一遇到困难的地方是尝试使用 kubernetes Ingress 资源映射到集群并扇出到我的微服务（它们是小型 Go 或 Node 后端）。我有将入口映射到不同服务的配置设置，那里没有问题。

我知道当你创建一个入口资源时，你真的可以很容易地让 GCP 启动一个 LoadBalancer。这很好，但它也代表了另外 20 美元/月，增加了项目成本。一旦/如果这件事得到一些关注，那可以忽略不计，但现在以及为了更好地理解 Kubernetes，我想执行以下操作：

• 从 GCP 获取静态 IP，
• 将它与入口资源一起使用
• 在同一个集群中托管负载均衡器（使用 nginx 负载均衡器）
• 避免为外部负载均衡器付费

有什么办法甚至可以使用 Kubernetes 和入口资源来完成吗？

谢谢！

我尝试在kubernetes群集上配置入口。我按照文档安装了入口控制器并运行了以下命令

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/baremetal/service-nodeport.yaml

在运行默认的http-backend和nginx-ingress-controller之后：

ingress-nginx   default-http-backend-846b65fb5f-6kwvp      1/1       Running   0          23h       192.168.2.28   node1
ingress-nginx   nginx-ingress-controller-d658896cd-6m76j   1/1       Running   0          6m        192.168.2.31   node1

我尝试测试入口，并部署了以下服务：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      containers:
        - name: my-echo
          image: gcr.io/google_containers/echoserver:1.8
---
apiVersion: v1
kind: Service
metadata:
  name: echoserver-svc
spec:
  selector:
    app: echo
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

以及以下入口：

apiVersion: extensions/v1beta1
kind: Ingress …

因此，我有一个入口控制器将流量路由到三个不同的服务，但只有一个正在工作，所有其他服务都返回 503。INGRESS YAML

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  namespace: dev
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
spec:
  rules:
  - host: localhost
    http:
      paths:
      - path: /equip
        backend:
            serviceName: web-equip-svc-2
            servicePort: 18001
      - path: /hello
        backend:
            serviceName: hello-service
            servicePort: 80
      - path: /equip-ws
        backend:
            serviceName: web-equip-svc-2
            servicePort: 18000

工作 SVC YAML

apiVersion: v1
kind: Service
metadata:
  name: hello-service
  namespace: linkerd-test
  labels:
    app: hello
spec:
  type: ClusterIP
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

无法使用 SVC YAML …

我正在添加一个入口，如下所示：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cheddar
spec:
  rules:
  - host: cheddar.213.215.191.78.nip.io
    http:
      paths:
      - backend:
          service:
            name: cheddar
            port:
              number: 80
        path: /
        pathType: ImplementationSpecific

但日志抱怨：

W0205 15:14:07.482439       1 warnings.go:67] extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
time="2021-02-05T15:14:07Z" level=info msg="Updated ingress status" namespace=default ingress=cheddar
W0205 15:18:19.104225       1 warnings.go:67] networking.k8s.io/v1beta1 IngressClass is deprecated in v1.19+, unavailable in v1.22+; use networking.k8s.io/v1 IngressClassList

为什么？什么是正确的 yaml 使用？我目前在 microk8s 1.20

我在让我的Ingress控制器在Google Container Engine上运行时遇到了困难.我想使用具有Basic Auth的NGINX Ingress Controller并使用保留的全局静态IP名称(可以在Google Cloud Admin界面的外部IP地址部分中进行).当我使用gce类时,一切正常,除了Basic Auth(我认为gce类不支持),当我尝试使用入口控制器启动的nginx类但是我保留的IP地址时,会输入代码Google Cloud Admin界面不会附加到Ingress Controller.有谁知道如何使这个工作？这是我的配置文件:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: webserver
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "myreservedipname"
    kubernetes.io/ingress.class: "nginx"
    ingress.kubernetes.io/auth-type: basic
    ingress.kubernetes.io/auth-realm: "Auth required"
    ingress.kubernetes.io/auth-secret: htpasswd
spec:
  tls:
    - secretName: tls
  backend:
    serviceName: webserver
    servicePort: 80

我有 kubeadm 和 Kubernetes v1.12，没有 AWS 或 Google Cloud。

我想知道安装的 Kubernetes 集群是否已经有一个入口控制器，如果它有两个默认值。

谢谢 ：）

当一个请求需要超过 60 秒来响应时，入口控制器似乎会反弹

从我可以看到我们的 NGINX 入口控制器在处理一个请求超过 60 秒后返回 504 给客户端。我可以从 NGINX 日志中看到这一点：

2019/01/25 09:54:15 [error] 2878#2878: *4031130 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.244.0.1, server: myapplication.com, request: "POST /api/text HTTP/1.1", upstream: "http://10.244.0.39:45606/api/text", host: "myapplication.com"
10.244.0.1 - [10.244.0.1] - - [25/Jan/2019:09:54:15 +0000] "POST /api/text HTTP/1.1" 504 167 "-" "PostmanRuntime/7.1.6" 2940 60.002 [default-myapplication-service-80] 10.244.0.39:45606 0 60.000 504 bdc1e0571e34bf1223e6ed4f7c60e19d

第二个日志项显示上游响应时间和请求时间均为 60 秒（请参阅此处的 NGINX 日志格式）

但是我在入口配置中将所有超时值指定为 3 分钟：

apiVersion: extensions/v1beta1 …

Waiting for http-01 challenge propagation: failed to perform self check GET request，它类似于此错误https://github.com/jetstack/cert-manager/issues/656， 但 GitHub 票证评论中的所有解决方案都没有帮助。

我正在尝试CertManager按照本教程中的说明在 DigitalOcean 上进行设置：https : //www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on -digitalocean-kubernetes 我没有收到任何错误，但是来自的请求CertManager在挂起状态等待了 40 多个小时。

我已经使用 Nginx 成功配置了 Ingress，然后我创建了一个命名空间并创建了CertManagerCRD：

$ kubectl create namespace cert-manager
$ kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.12.0/cert-manager.yaml

我可以CertManager按预期看到所有豆荚：

$ kubectl get pods --namespace cert-manager
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-5c47f46f57-gxhwv              1/1     Running   0          42h
cert-manager-cainjector-6659d6844d-xp75s   1/1     Running   0          42h
cert-manager-webhook-547567b88f-k4dv2      1/1     Running   0          42h

然后我创建了登台发行者：

$ kubectl …

我们有一个由kubernetes ingress创建的HTTP(s)Load Balancer,它指向由运行nginx和Ruby on Rails的pod组成的后端.

看一下负载均衡器日志,我们检测到越来越多的请求,响应代码为0和statusDetails= client_disconnected_before_any_response.

我们试图理解为什么会发生这种情况,但我们没有找到任何相关的东西.nginx访问或错误日志中没有任何内容.

这种情况发生在从GET到POST的多种请求中.

我们还怀疑有时尽管请求记录了该错误,但请求实际上是传递给后端的.例如,我们看到了PG :: UniqueViolation错误,因为在我们的注册终端中,两次发送了令人满意的注册请求到后端.

任何形式的帮助将不胜感激.谢谢!

 更新1

这里要求的是入口资源的yaml文件:

 更新2

我已经创建了一个基于日志的Stackdriver度量标准,用于计算出现此行为的请求数.这是图表:

大峰大致匹配这些kubernetes事件的时间戳:

完整错误: Readiness probe failed: Get http://10.48.1.28:80/health_check: net/http: request canceled (Client.Timeout exceeded while awaiting headers)"

因此有时候后端后面的pod的准备探测失败了,但并非总是如此.

这是readinessProbe的定义

readinessProbe:
  failureThreshold: 3
  httpGet:
    httpHeaders:
    - name: X-Forwarded-Proto
      value: https
    - name: Host
      value: [redacted]
    path: /health_check
    port: 80
    scheme: HTTP
  initialDelaySeconds: 1
  periodSeconds: 30
  successThreshold: 1
  timeoutSeconds: 5

我找不到指定当附属部署使用多个副本扩展时 Kubernetes 服务行为方式的文档。

我假设有某种负载平衡。是否与服务类型有关？

此外，我希望在服务转发的请求中具有某种关联性（即，如果可能，所有具有特定后缀的请求应始终映射到同一个 pod，等等）。这是可以实现的吗？我见过的关闭是Ambassador，但这是服务级别的亲和力，而不是 pod 级别。