如何在Ak集群中发生Pod故障时识别实际异常

如何解决如何在Ak集群中发生Pod故障时识别实际异常

我正在使用Ev2将dotnetcore mvc应用程序部署到aks集群。吊舱状态为“ CrashLoopBackOff”。当我查看带有kubectl的日志时，我看到一些警告，但根本看不到任何异常。应用程序运行状况链接失败，并显示404错误。我相信它可以输入启动文件，因为在日志中出现了使用kestrel的事件，但是我想知道导致应用程序关闭的故障发生在哪里。任何输入都会有很大帮助。

注意：粘贴到这里时，有一个我已用隐藏键替换的键

C:\Users\jeevanm>kubectl logs  <pod-name> -n mynamespace
←[40m←[1m←[33mwarn←[39m←[22m←[49m: Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository[60]
      Storing keys in a directory '/root/.aspnet/DataProtection-Keys' that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed.
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]
      User profile is available. Using '/root/.aspnet/DataProtection-Keys' as key repository; keys will not be encrypted at rest.
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[58]
      Creating key {<hidden key>} with creation date 2020-10-29 02:59:54Z,activation date 2020-10-29 02:59:54Z,and expiration date 2021-01-27 02:59:54Z.
←[40m←[1m←[33mwarn←[39m←[22m←[49m: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35]
      No XML encryptor configured. Key {<hidden key>} may be persisted to storage in unencrypted form.
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository[39]
      Writing data to file '/root/.aspnet/DataProtection-Keys/key-<hidden-key>.xml'.
←[40m←[1m←[33mwarn←[39m←[22m←[49m: Microsoft.AspNetCore.Server.Kestrel[0]
      Overriding address(es) 'https://+:443'. Binding to endpoints defined in UseKestrel() instead.
Hosting environment: Production
Content root path: /app
Now listening on: https://0.0.0.0:443
Application started. Press Ctrl+C to shut down.
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/2 GET https://10.60.1.248:443/health
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished in 66.2889ms 404
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/2 GET https://10.60.1.248:443/health
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished in 2.0592ms 404
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/2 GET https://10.60.1.248:443/health
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished in 5.1835ms 404
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/2 GET https://10.60.1.248:443/health
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished in 2.2746ms 404
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/2 GET https://10.60.1.248:443/health
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished in 1.4105ms 404
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/2 GET https://10.60.1.248:443/health
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished in 2.104ms 404
Application is shutting down...