apache—您能否使用专用连接为kubernetes liveness端点提供服务,这些连接在常规连接池耗尽时可用?

xnifntxz  于 2021-10-10  发布在  Java
关注(0)|答案(1)|浏览(325)

当我们的豆荚耗尽,可能需要一些扩展,Kubernetes混淆这种耗尽与死亡,并重新启动我们的豆荚:s。当然,这会产生相反的效果,剩余的pod:s会得到更多的负载。。。所以我的问题来了,你能为kubernetes和lb liveness和readiness端点提供专用的、不耗尽的连接吗?
我们有一个在kubernetes中运行的旧系统,每个pod中捆绑了一个ApacheHTTPD和一个tomcat。负载平衡由kubernetes在不同的pod之间完成,而不是在httpd中。httpd正在运行mpm_event+mod_jk,并且有一个到tomcat的ajp1.3连接。httpd也在不使用tomcat的情况下从磁盘提供一些静态资源。当出现故障时,我们很快就会耗尽ajp线程和httpd工作人员。
基本上我们看到的是:
应用程序无法连接到某些资源。某些网络、memcached、db或其他服务开始超时。等待超时会导致线程非常长寿,我们很快就会用完线程。
准备就绪/活跃度探测器没有及时响应,kubernetes重新启动pod(或者,在我们移除活跃度探测器后,使用准备就绪的lb将它们从负载平衡中移除,具有基本相同的效果)。
根本原因问题(以某种方式)得到了解决,但现在负载平衡中剩下的(非)pod:s太少了。当一个吊舱返回时,它会被所有的流量击中,筋疲力尽,并从lb中移除,因为它在准备就绪探测器上再次太慢。
我们现在发现很难摆脱这种状态(到目前为止,它发生了两次,我们基本上必须切断cloudflare waf上的所有通信,直到有足够的pod:s重新启动/进入负载平衡…)
我对解决方案的想法:
我想我可以从httpd->tomcat为活跃度和准备度端点打开一个优先快速通道,见下文。但是,我能否以某种方式将httpd(mpm_事件)中的工作人员专用于这些端点?否则,当我的httpd工作人员用完时,我想我的快车道不会提供任何帮助。或者关于如何确保我们始终能够为活跃/准备服务的任何其他想法,只要雄猫还活着,即使它已经精疲力竭?
这是我当前的httpd工作程序设置:

<IfModule mpm_event_module>
    StartServers             3
    ServerLimit             36
    MinSpareThreads         75
    MaxSpareThreads        250
    ThreadsPerChild         25
    MaxRequestWorkers      900
    MaxConnectionsPerChild   0
</IfModule>

也许只需要工作人员分析请求并找出uri…:-/或者我可以用某种方式将一个特定的员工库奉献给活力和准备???
my httpd->tomcat fastlane:
我当时正在处理与tomcat的第二个ajp连接,专门用于就绪性和活跃性端点。乍一看,它似乎奏效了。
在server.xml中,我在端口8008上添加了一个连接器:

<Connector
        port="8009"
        protocol="AJP/1.3"
        redirectPort="8443"
        connectionTimeout="60000"
        minSpareThreads="2"
        maxThreads="20"
        acceptorThreadCount="2"
        URIEncoding="UTF-8"
        address="127.0.0.1"
        secretRequired="false" />

    <!--
      This is the prioritized connector used for health checks.
    -->
    <Connector
        port="8008"
        protocol="AJP/1.3"
        redirectPort="8443"
        connectionTimeout="-1"
        keepAliveTimeout="-1"
        acceptorThreadPriority="6"
        minSpareThreads="2"
        maxThreads="5"
        acceptorThreadCount="1"
        URIEncoding="UTF-8"
        address="127.0.0.1"
        secretRequired="false" />

在我的 workers.properties (jkworkersfile)我添加了新连接并将其命名 ajp13prio :

worker.list=ajp13,ajp13prio
worker.ajp13.type=ajp13
worker.ajp13.port=8009
worker.ajp13.host=127.0.0.1
worker.ajp13.lbfactor=1
worker.ajp13prio.type=ajp13
worker.ajp13prio.port=8008
worker.ajp13prio.host=127.0.0.1
worker.ajp13prio.lbfactor=1

在我的httpd conf中,我将探针配置为使用新连接器:

<VirtualHost *:80>
...
    # health checks (readiness and liveness probes) are prioritized
    JkMount /api/v2/health/* ajp13prio

    # All requests go to worker1 by default
    JkMount /* ajp13
...
</VirtualHost>
l3zydbqr

l3zydbqr1#

如果有人在这里,在kubernetes中运行一个旧的apache设置,那么就到此结束。
最后,我向tomcat添加了第二个连接器,它是http,而不是ajp。该连接器的端口从容器中露出,由lb和kubernetes使用。因此,健康检查完全绕过了httpd。然后,此端口(默认情况下)在lb中被阻止,以便进行外部访问。
server.xml

<Connector
        port="8080"
        address="0.0.0.0"
        protocol="HTTP/1.1"
        enableLookups="false"
        maxThreads="5"
        minSpareThreads="2"
        acceptorThreadCount="1"
        acceptorThreadPriority="9"
        connectionTimeout="2000"
        keepAliveTimeout="-1"
        disableUploadTimeout="false"
        connectionUploadTimeout="3600000"
        redirectPort="8443"
        URIEncoding="UTF-8"
        maxPostSize="1" />

部署.yaml

tomcat container:
          readinessProbe:
            httpGet:
              path: /health/readiness
              port: 8080
            initialDelaySeconds: 120
          livenessProbe:
            httpGet:
              path: /health/liveness
              port: 8080
          ports:
            - name: ajp
              containerPort: 8009
              protocol: TCP
            - name: http-prio
              containerPort: 8080
              protocol: TCP

service.yaml:

apiVersion: v1
kind: Service
metadata:
...
  annotations:
    cloud.google.com/backend-config: '{"default": "app-backendconfig"}'
spec:
  ports:
  - name: http
    port: 80
  - name: http-prio
    port: 8080

...

backendconfig.yaml

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
...
spec:
...
  healthCheck:
    type: HTTP
    requestPath: /health/readiness
    port: 8080

相关问题