Triton server multiple initialization errors, under kubernetes

Hello, hope someone can help me, I am reading the following in the log;

$ kubectl logs test-triton-triton-inference-server-8b7bc6c84-drpn9

=============================
== Triton Inference Server ==
=============================

NVIDIA Release 20.08 (build 15533555)

Copyright (c) 2018-2020, NVIDIA CORPORATION.  All rights reserved.

Various files include modifications (c) NVIDIA CORPORATION.  All rights reserved.
NVIDIA modifications are covered by the license terms that apply to the underlying
project or file.
find: '/usr/lib/ssl/private': Permission denied

NOTE: The SHMEM allocation limit is set to the default of 64MB.  This may be
   insufficient for the inference server.  NVIDIA recommends the use of the following flags:
   nvidia-docker run --shm-size=1g --ulimit memlock=-1 --ulimit stack=67108864 ...

I1016 08:14:03.413740 1 metrics.cc:184] found 1 GPUs supporting NVML metrics
I1016 08:14:03.419300 1 metrics.cc:193]   GPU 0: GeForce GTX 1080 Ti
I1016 08:14:03.419579 1 server.cc:119] Initializing Triton Inference Server
error: creating server: Internal - Unable to create GCS client. Check account credentials.

I am new to kubernetes environment, what can be done to make it function properly? (there are 2 equal GPU hardware installed in the system, and this is a local install. I prefer to use persistent volume for model repo, but failed. Trying gc now but there are still some problems. Any comments for the above appreciated.

Thanks, Alper

[deadeyegoodwin]

I’m still not sure if you are saying that you believe something is wrong or not. What are you expecting curl to do in these cases? By default curl just prints the body of the response (as in the last case). But for the first 3 there is nothing in the response body. All these endpoints do is return an HTTP status. You can see that status with -v or by using the -w flag as I showed… that is entirely up to how you want to use curl.

[ontheway16]

I was hoping to see some response, in fact, like the one in this link. (As presented few messages above, /api/status also returns 400, with -v). But anyway, directing the client script to the pod_IP:port returns the correct output of inference, so I can assume no problems here, thank you again.