Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Executing command in pod fails when _request_timeout is passed in tuple format #2292

Open
tusharrobin opened this issue Oct 8, 2024 · 5 comments
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@tusharrobin
Copy link

tusharrobin commented Oct 8, 2024

What happened (please include outputs or screenshots):

Executing command in pod fails if _request_timeout is passed as tuple.
The exact error is
Exception when calling CoreV1Api->connect_get_namespaced_pod_exec: (0) Reason: '<' not supported between instances of 'float' and 'tuple'

What you expected to happen:
Expected to run the command successfully.

How to reproduce it (as minimally and precisely as possible):

`from kubernetes import client, config
from kubernetes.stream import stream

def run_command_in_pod(namespace, pod_name, container_name, command, timeout):
config.load_kube_config()
c = client.Configuration()
c.debug = True
api_instance = client.CoreV1Api()

exec_command = [
    '/bin/sh',
    '-c',
    command
]

try:
    response = stream(api_instance.connect_get_namespaced_pod_exec,
                      pod_name,
                      namespace,
                      container=container_name,
                      command=exec_command,
                      stderr=True, stdin=False,
                      stdout=True, tty=False,
                      _request_timeout=timeout)
    print("Command output: ", response)
except client.exceptions.ApiException as e:
    print("Exception when calling CoreV1Api->connect_get_namespaced_pod_exec: %s\n" % e)

if name == 'main':
namespace = 'test'
pod_name = 'test'
container_name = 'test'
command = 'date'
timeout = (5, 10)

run_command_in_pod(namespace, pod_name, container_name, command, timeout)`

Anything else we need to know?:

Environment:

  • Kubernetes version (kubectl version): 1.30
  • OS (e.g., MacOS 10.13.6): Rocky 8.6
  • Python version (python --version) 3.9
  • Python client version (pip list | grep kubernetes) kubernetes-31.0.0
@tusharrobin tusharrobin added the kind/bug Categorizes issue or PR as related to a bug. label Oct 8, 2024
@roycaihw
Copy link
Member

roycaihw commented Oct 9, 2024

/assign @yliaog

@yliaog
Copy link
Contributor

yliaog commented Oct 9, 2024

timeout should be a float, not a tuple as the error suggests

Exception when calling CoreV1Api->connect_get_namespaced_pod_exec: (0) Reason: '<' not supported between instances of 'float' and 'tuple'

@tusharrobin
Copy link
Author

tusharrobin commented Oct 9, 2024

Hi @yliaog, Thanks for looking into this.

The documentation for the API mentions
:param _request_timeout: timeout setting for this request. If one number provided, it will be total request timeout. It can also be a pair (tuple) of (connection, read) timeouts.

Reference: https://raw.githubusercontent.com/kubernetes-client/python/refs/heads/master/kubernetes/client/api/core_v1_api.py

If there is another way to set connect_timeout, let me know. Thanks again !

@yliaog
Copy link
Contributor

yliaog commented Oct 9, 2024

@tusharrobin
Copy link
Author

tusharrobin commented Oct 9, 2024

In case if the pod is on a node which is network partitioned and if you execute command in a pod running on that node, it will take 30 seconds to timeout even if you set "_request_timeout" to be a lesser value.

If you use curl with "connect_timeout" to a smaller value, it does timeout after that duration so we need to set connect_timeout for the "connect_get_namespaced_pod_exec" api so that it can timeout during network partition.

The only option I see in kubernetes client is to set the _request_timeout to a tuple value which allows to set "connect_timeout" which is not working. Can you please check if there is an issue ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

No branches or pull requests

3 participants