Shinyproxy: shinyproxyデプロイメントのローリングアップデートにより、孤立したポッドが発生します

作成日 2019年08月19日  ·  7コメント  ·  ソース: openanalytics/shinyproxy

こんにちは、application.yamlに変更があり、ローリングアップデートが選択された場合(レプリカを0に設定してから1に戻す)-主に新しいshinyproxyイメージをアーティファクトからダウンロードする必要があるため-以前のすべてのポッド前のshinyproxyによってスピンアップされ、ゾンビとして取り残されます

再現するには:

  • kubectl get all

NAME READY STATUS RESTARTS AGE
pod /shinyproxy-7f76d48c79-8x9hs2/2ランニング041m

名前タイプクラスター-IP外部-IPポート年齢
service / shinyproxy NodePort 172.30.85.1918080:32094 / TCP 40m

名前希望する現在の最新の利用可能な年齢
deploy.apps / shinyproxy 1 1 1 1 41m

希望する現在の準備年齢の名前
Replicaset.apps / shinyproxy-7f76d48c79 1 1 1 41m

NAME HOST / PORT PATH SERVICES PORT TERMINATION WILDCARD
route.route.openshift.io/shinyproxy shinyproxy-aap.apps.cpaas.service.test shinyproxyなし

  • アプリにログオンします(私の場合、LDAP認証と/ app_direct /を使用して光沢のあるアプリケーションに接続します(アプリケーションの新しいポッドが起動します)-予想どおり

NAME READY STATUS RESTARTS AGE
pod /shinyproxy-7f76d48c79-8x9hs2/2ランニング043m
pod /sp-pod-e7603441-03ba-470b-925a-22cfba1716de1/1実行中012s

名前タイプクラスター-IP外部-IPポート年齢
service / shinyproxy NodePort 172.30.85.1918080:32094 / TCP 43m

名前希望する現在の最新の利用可能な年齢
deploy.apps / shinyproxy 1 1 1 1 43m

希望する現在の準備年齢の名前
Replicaset.apps / shinyproxy-7f76d48c79 1 1 1 43m

NAME HOST / PORT PATH SERVICES PORT TERMINATION WILDCARD
route.route.openshift.io/shinyproxy shinyproxy-aap.apps.cpaas.service.test shinyproxyなし

  • 新しいshinyproxyイメージのビルド後:

kubectl scale --replicas=0デプロイメント/shinyproxy
展開.extensions/shinyproxyscaled

kubectl scale --replicas=1デプロイメント/shinyproxy
展開.extensions/shinyproxyscaled

  • 作成中の光沢のあるプロキシとコンテナの新しいイメージがダウンロードされました。

NAME READY STATUS RESTARTS AGE
pod / shinyproxy-7f76d48c79-l5fvw 0/2 ContainerCreating 0 4s
pod /sp-pod-e7603441-03ba-470b-925a-22cfba1716de1/1ランニング01m

名前タイプクラスター-IP外部-IPポート年齢
service / shinyproxy NodePort 172.30.85.1918080:32094 / TCP 44m

名前希望する現在の最新の利用可能な年齢
deploy.apps / shinyproxy 1 1 1 0 45m

希望する現在の準備年齢の名前
Replicaset.apps / shinyproxy-7f76d48c79 1 1 0 45m

NAME HOST / PORT PATH SERVICES PORT TERMINATION WILDCARD
route.route.openshift.io/shinyproxy shinyproxy-aap.apps.cpaas.service.test shinyproxyなし

  • この段階では、私のWebアプリケーションは応答しません。タブ/ウィンドウを閉じるだけです。 また、ポッド(Rアプリケーション用)は、手動で削除しない限り、そのまま残ります。

  • リソースを消費しているポッドにはアクセスできません。これは、新しいサービスが更新されたデプロイメントを指し、アプリケーションはサービスを介したルートを介してのみアクセスできるためです。

  • また、どのポッドが古くなっているかを特定して手動で削除することも非常に困難です。

最も参考になるコメント

この問題の解決策を見つけました。 Spring Bootアプリは正しく正常にシャットダウンされるため、これは実際にはshinyproxyまたはcontainerproxyでは問題になりません。

問題はkubctl proxyサイドカーコンテナです。 Kubernetesの場合、containerproxyがサイドカーコンテナに依存してKubernetes自体と通信することは明らかではありません。 そのため、新しいデプロイでは、Kubernetesはすべての古いポッドのプロキシとサイドカーコンテナの両方にSIGTERMを送信します。 サイドカーコンテナはすぐに終了し、containerproxyはKubernetesとの通信に失敗します。

ここに記載されているように、Kubernetesがv1.18でこれらの起動とシャットダウンの依存関係を解決しようとしていることを読みました。
https://github.com/kubernetes/enhancements/issues/753
https://banzaicloud.com/blog/k8s-sidecars/

それまでは、サイドカーコンテナに次のライフサイクルアノテーションを付ける簡単な回避策があります。

          lifecycle:
            preStop:
              exec:
                command: ["sh", "-c", "sleep 5"] # wait 5 seconds to let shinyproxy remove the pods on graceful shutdown

全てのコメント7件

こんにちは@ramkumarg1

shinyproxyがSIGTERMシグナルとして受信した場合(デプロイメントがスケールダウンされた場合)、最初にすべてのアプリケーションポッドを停止して正常に終了する必要があります。 ポッド仕様で猶予期間terminationGracePeriodSeconds増やす必要がある場合があります(デフォルトは30秒)。 shinyproxyがこの期間内に終了できない場合、SIGKILLを受け取り、すぐに終了して、孤立したポッドを残します。 詳細はこちら: https ://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/

@dseynaevに感謝します。デプロイメントの仕様を変更して、terminationGracePeriodSecondsを含めましたが、違いはありませんでした。 ポッドはすぐに強制終了されました-おそらく、この問題はhttps://github.com/kubernetes/kubernetes/issues/47576にリンクされており、スプリングブートでSIGTERMを適切に処理する必要がありますか?

spec:
  terminationGracePeriodSeconds : 180
  containers:
  - name: shinyproxy

ゾンビポッドでも同じ問題が発生しますが、終了猶予期間の設定でもこれは解決されません。

私は同じ問題を抱えており、これは終了時にshiny /containerproxyによってログに記録されるものです:

2020-01-30 10:56:56.785  INFO 1 --- [           main] e.o.c.ContainerProxyApplication          : Started ContainerProxyApplication in 39.115 seconds (JVM running for 43.619)
2020-01-30 10:57:01.374  INFO 1 --- [  XNIO-2 task-1] io.undertow.servlet                      : Initializing Spring FrameworkServlet 'dispatcherServlet'
2020-01-30 10:57:01.375  INFO 1 --- [  XNIO-2 task-1] o.s.web.servlet.DispatcherServlet        : FrameworkServlet 'dispatcherServlet': initialization started
2020-01-30 10:57:01.507  INFO 1 --- [  XNIO-2 task-1] o.s.web.servlet.DispatcherServlet        : FrameworkServlet 'dispatcherServlet': initialization completed in 131 ms
2020-01-30 10:57:26.275  INFO 1 --- [ XNIO-2 task-16] e.o.containerproxy.service.UserService   : User logged in [user: **]
2020-01-30 10:57:35.802  INFO 1 --- [  XNIO-2 task-3] e.o.containerproxy.service.ProxyService  : Proxy activated [user: ***] [spec: insight] [id: 9274ad33-665a-4d47-bab5-6c4b39a618b8]
2020-01-30 10:59:02.376  INFO 1 --- [       Thread-2] ConfigServletWebServerApplicationContext : Closing org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext<strong i="6">@2b2948e2</strong>: startup date [Thu Jan 30 10:56:24 GMT 2020]; root of context hierarchy
2020-01-30 10:59:02.377 ERROR 1 --- [pool-4-thread-1] java.io.InputStreamReader                : Error while pumping stream.
java.io.EOFException: null
    at okio.RealBufferedSource.require(RealBufferedSource.java:61) ~[okio-1.15.0.jar!/:na]
    at okio.RealBufferedSource.readHexadecimalUnsignedLong(RealBufferedSource.java:303) ~[okio-1.15.0.jar!/:na]
    at okhttp3.internal.http1.Http1Codec$ChunkedSource.readChunkSize(Http1Codec.java:469) ~[okhttp-3.12.0.jar!/:na]
    at okhttp3.internal.http1.Http1Codec$ChunkedSource.read(Http1Codec.java:449) ~[okhttp-3.12.0.jar!/:na]
    at okio.RealBufferedSource$1.read(RealBufferedSource.java:439) ~[okio-1.15.0.jar!/:na]
    at java.io.InputStream.read(InputStream.java:101) ~[na:1.8.0_171]
    at io.fabric8.kubernetes.client.utils.BlockingInputStreamPumper.run(BlockingInputStreamPumper.java:49) ~[kubernetes-client-4.2.2.jar!/:na]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_171]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_171]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_171]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_171]
    at java.lang.Thread.run(Thread.java:748) [na:1.8.0_171]
2020-01-30 10:59:02.394  INFO 1 --- [       Thread-2] o.s.j.e.a.AnnotationMBeanExporter        : Unregistering JMX-exposed beans on shutdown
2020-01-30 10:59:02.403  INFO 1 --- [       Thread-2] o.s.j.e.a.AnnotationMBeanExporter        : Unregistering JMX-exposed beans
2020-01-30 10:59:02.514  WARN 1 --- [       Thread-2] .s.c.a.CommonAnnotationBeanPostProcessor : Invocation of destroy method failed on bean with name 'proxyService': eu.openanalytics.containerproxy.ContainerProxyException: Failed to stop container
2020-01-30 10:59:02.525  INFO 1 --- [       Thread-2] io.undertow.servlet                      : Destroying Spring FrameworkServlet 'dispatcherServlet'

この問題の解決策を見つけました。 Spring Bootアプリは正しく正常にシャットダウンされるため、これは実際にはshinyproxyまたはcontainerproxyでは問題になりません。

問題はkubctl proxyサイドカーコンテナです。 Kubernetesの場合、containerproxyがサイドカーコンテナに依存してKubernetes自体と通信することは明らかではありません。 そのため、新しいデプロイでは、Kubernetesはすべての古いポッドのプロキシとサイドカーコンテナの両方にSIGTERMを送信します。 サイドカーコンテナはすぐに終了し、containerproxyはKubernetesとの通信に失敗します。

ここに記載されているように、Kubernetesがv1.18でこれらの起動とシャットダウンの依存関係を解決しようとしていることを読みました。
https://github.com/kubernetes/enhancements/issues/753
https://banzaicloud.com/blog/k8s-sidecars/

それまでは、サイドカーコンテナに次のライフサイクルアノテーションを付ける簡単な回避策があります。

          lifecycle:
            preStop:
              exec:
                command: ["sh", "-c", "sleep 5"] # wait 5 seconds to let shinyproxy remove the pods on graceful shutdown

@fmannhardtの修正でこれが解決されることを確認できます。 どうもありがとう!

こんにちは、みんな

最近のバージョンのShinyProxy(正確にはどのバージョンかはわかりませんが、少なくともShinyProxy 2.3.1)では、kube-proxyサイドカーを使用する必要はありません。 ShinyProxyは、KubernetesAPIの場所と認証を自動的に検出します。
したがって、この問題は自動的に解決されると思います。
それでも、お時間を割いてご調査いただきありがとうございます!

このページは役に立ちましたか?
0 / 5 - 0 評価

関連する問題

lucius-verus-fan picture lucius-verus-fan  ·  7コメント

fmmattioni picture fmmattioni  ·  3コメント

lucius-verus-fan picture lucius-verus-fan  ·  8コメント

shrektan picture shrektan  ·  9コメント

erossini picture erossini  ·  3コメント