如何将来自nginx pod的请求转发到对应的php pod？

如何解决如何将来自nginx pod的请求转发到对应的php pod？

我正在尝试在 Azure Kubernetes 服务上部署我的 php symfony 应用程序。我有以下 deployment.yaml 用于 php pod

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myphp-deployment
  labels:
    app: php
spec:
  replicas: 1
  selector:
    matchLabels:
      app: php
  template:
    metadata:
      labels:
        app: php
    spec:
      containers:
      - name: php
        image: myimage
        ports:
        - containerPort: 9000

这里是 php 服务 yaml

apiVersion: v1
kind: Service
metadata:
  name: php
spec:
  selector:
    app: php
  ports:
    - protocol: TCP
      port: 9000
      targetPort: 9000

这是我的 nginx 部署 yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mynginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: myimage
        ports: 
        - containerPort: 80

还有我的 nginx-service yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
type: LoadBalancer

上述设置到位后，一切正常。但是，如果我将副本集增加到两个，即 php pod 的 replicas:2，应用程序不会始终保持状态。

我发现来自我的 nginx pod 的请求被转发到两个副本（php）中的任何一个，并且它正在将我注销。有时，它让我登录，但应用程序的行为不一致。

我如何控制请求应该转发到哪个副本集？或者，如果现有 pod 出现故障，是否可以动态配置另一个副本？

P.S 我对 Kubernetes 很陌生

解决方法

如何控制请求应该转发到哪个副本集？

您要查找的是会话亲和性或粘性会话。这可以通过入口来实现。 kubernetes 入口控制器，例如 Nginx ingress 控制器已经考虑并实现了这些要求。入口控制器用 Set-Cookie 标头回复第一个请求的响应。 cookie 的值将映射到特定的 pod 副本。当后续请求再次返回时，客户端浏览器将附加 cookie，因此入口控制器能够将流量路由到同一个 pod 副本。

Kubernetes 具有使用 StatefulSet 之类的稳定 Pod 名称或使用 Headless Service 发现 Pod 集的机制，但是这些解决方案虽然很棒，但在您的用例中不如粘性会话好.尽管如此，如果您对 Kubernetes 完全陌生，还是值得一试。

或者，如果现有 Pod 出现故障，是否可以动态配置另一个副本？

如果您的应用程序崩溃，Kubernetes 将尝试重新启动它。这是由Container restart policy控制的：

Pod 的 spec 有一个 restartPolicy 字段，可能 值 Always、OnFailure 和 Never。默认值为始终。

restartPolicy 适用于 Pod 中的所有容器。 restartPolicy 仅指容器的重启 kubelet 在同一个节点上。 Pod 中的容器退出后，kubelet 以指数退避延迟（10 秒、20 秒、40 秒……）重新启动它们， 最多五分钟。一旦容器执行了 10 分钟没有任何问题，kubelet 重置重启退避 该容器的计时器。

在某些情况下，您可能会遇到应用程序正在崩溃或无法正常工作，但仍然没有崩溃/重新启动的情况。在这种情况下，您可以使用 Kubernetes livenessProbe。 Kubernetes 可以通过活性探针检查容器是否还活着。您可以在 pod 的规范中为每个容器指定一个 liveness 探针。 Kubernetes 会定期执行探针并在探针失败时重新启动容器。