Error running dotnet core 3.0 docker image on Kubernetes

10/21/2019

Steps to reproduce the issue

  1. Create a webapi project template using the dotnet CLI (dotnet --version = 3.0.100)
  2. Build the dockerfile to create image (see dockerfile below)
  3. Run the docker image on local docker (works fine)
  4. Push this docker image to a docker registry
  5. Deploy this onto K8s (were using EKS on AWS)

Expected behavior

Pod starts up, and runs the webapi

Actual behavior

Pod fails to start up, with the following error in logs:

terminate called after throwing an instance of 'boost::wrapexcept<util::AprException>'
  what():  BaseException: Could not find the requested symbol. at /opt/jenkins/oa-s173/cmake-64-d/agent/native/shared/libutil/src/main/cpp/util/AprException.h:54 at static void util::AprException::check(apr_status_t)
  at liboneagentdotnet.so [0x90ec22]
  at liboneagentdotnet.so [0x90ed1b]
  at liboneagentdotnet.so [0x90ed7c]
  at liboneagentdotnet.so [0x143d61]
  at liboneagentdotnet.so [0x144adb]
  at unknown [0x7f4a024acee2]
  at unknown [0x7f4a024accef]
  at unknown [0x7f4a024a4e48]
  at unknown [0x7f4a024acb40]
  at unknown [0x7f4a024aca6c]
  at unknown [0x7f4a024ac77a]
  at unknown [0x7f4a024a3299]
  at unknown [0x7f4a024a2dd1]
  at unknown [0x7f4a024a2d4e]
  at unknown [0x7f4a024a2425]
  at unknown [0x7f4a020ac426]
  at unknown [0x7f4a020aca3d]
  at libcoreclr.so(CallDescrWorkerInternal+0x7b) [0x24dcae]
  at libcoreclr.so(CallDescrWorkerWithHandler(CallDescrData*, int)+0x74) [0x17dfc4]
  at libcoreclr.so(DispatchCallDebuggerWrapper(CallDescrData*, ContextTransitionFrame*, int)+0x86) [0x17e0b6]
  at libcoreclr.so(DispatchCallSimple(unsigned long*, unsigned int, unsigned long, unsigned int)+0xb6) [0x17e236]
  at libcoreclr.so(MethodTable::RunClassInitEx(Object**)+0x1a1) [0x115d61]
  at libcoreclr.so(MethodTable::DoRunClassInitThrowing()+0x2f8) [0x1162e8]
  at libcoreclr.so(JIT_GetSharedNonGCStaticBase_Helper+0xcf) [0x1b916f]
  at unknown [0x7f4a020ac2ea]
  at unknown [0x7f4a020ab4ec]
  at unknown [0x7f4a020aadad]
  at libcoreclr.so(CallDescrWorkerInternal+0x7b) [0x24dcae]
  at libcoreclr.so(CallDescrWorkerWithHandler(CallDescrData*, int)+0x74) [0x17dfc4]
  at libcoreclr.so(DispatchCallDebuggerWrapper(CallDescrData*, ContextTransitionFrame*, int)+0x86) [0x17e0b6]
  at libcoreclr.so(DispatchCallSimple(unsigned long*, unsigned int, unsigned long, unsigned int)+0xb6) [0x17e236]
  at libcoreclr.so(MethodTable::RunClassInitEx(Object**)+0x1a1) [0x115d61]
  at libcoreclr.so(MethodTable::DoRunClassInitThrowing()+0x2f8) [0x1162e8]
  at libcoreclr.so [0x29c00b]
  at libcoreclr.so [0x2551cc]
  at libcoreclr.so [0x2548c4]
  at libcoreclr.so [0x2546b3]
  at libcoreclr.so [0x29ba01]
  at libcoreclr.so(MethodTable::EnsureInstanceActive()+0x92) [0x115a92]
  at libcoreclr.so(MethodDesc::EnsureActive()+0x22) [0x109ae2]
  at libcoreclr.so [0x262507]
  at libcoreclr.so [0x26291f]
  at libcoreclr.so(CorHost2::ExecuteAssembly(unsigned int, char16_t const*, int, char16_t const**, unsigned int*)+0x240) [0xcae90]
  at libcoreclr.so(coreclr_execute_assembly+0xd3) [0xa3c63]
  at libhostpolicy.so [0x161c2]
  at libhostpolicy.so(corehost_main+0xcb) [0x16a1b]
  at libhostfxr.so [0x2ab0f]
  at libhostfxr.so [0x296a2]
  at libhostfxr.so(hostfxr_main_startupinfo+0x92) [0x246f2]
  at dotnet [0xc440]
  at dotnet [0xc9fd]
  at libc.so.6(__libc_start_main+0xea) [0x2409a]
  at dotnet(_start+0x28) [0x2f3f]

Additional information

dockerfile is below:

FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS build-env
WORKDIR /build

COPY /src .
RUN dotnet restore
RUN dotnet build
RUN dotnet publish -c Release -o ./out

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0
WORKDIR /app
COPY --from=build-env /build/out .
ENTRYPOINT ["dotnet", "Weather.dll"]

It is unusual that this is happening only on K8s, were testing this as part of a migration to dotnetcore 3.0

This behavior does not change when specifying the runtime flag when executing dotnet publish.

Output of docker version

Local docker for windows version: Docker version 19.03.2, build 6a30dfc
Container Runtime Version (on K8s):  docker://18.6.1

General Comments

Not totally sure what the issue is here, I would be happy with a mere understanding of the error.

-- Gerard Murphy
.net-core
docker
kubernetes

1 Answer

10/23/2019

This was caused by Dynatrace not supporting the version of dotnet core we were targeting. Disabling this resolved the issue.

-- Gerard Murphy
Source: StackOverflow