[Task](k8s-client): Overhaul of JavaScript Client for Kubernetes Communication

[andypf]

Description

This issue pertains to the revamp of a JavaScript package utilized for communication with Kubernetes. The existing client, written in JavaScript, contains a bug in the watch method. Kubernetes offers a feature called the watch method, which technically behaves as an endless stream that is intermittently closed on the server side. In such cases, the client must perform a recovery operation and resume the interrupted stream based on a version number.

The client was also converted during the migration to TypeScript; however, it still contains errors. As a result, the old client is currently in use.

Objectives

The primary objectives of this issue are as follows:

1. Identify Issues: Determine what exactly is not functioning correctly, including checking whether all types are correct.
2. Fix Watch Method Bug: Reproduce and resolve the error in the watch method.

Tasks

The following tasks need to be completed to resolve this issue:

• Review the TypeScript migration for accuracy in type definitions.
• Investigate and reproduce the bug in the watch method.
• Implement a fix for the identified issues.

Requirements

• Technical Skills: Proficiency in JavaScript and TypeScript, as well as familiarity with Kubernetes and its API methods (GET, POST, WATCH).
• Dev Environment: A development environment is required to test and implement changes. Instructions on how to set this up locally can be found here.
• Documentation: Documentation on the Kubernetes API methods can be found
  • [Kubernetes API Overview] https://kubernetes.io/docs/concepts/api-overview/
  • Kubernetes API Description
  • Using Kubernetes API

Additional Information

• Option for Rewrite: If it proves easier or faster, feel free to completely rewrite the client.
• Expected Outcome: The expected outcome is a fully functional TypeScript client that correctly implements the watch method and interacts smoothly with Kubernetes.
• How the Watch Mechanism Works

  1. Establishing a Watch:

     • When a client makes a request to the Kubernetes API to "watch" a resource, it sends an HTTP request with the WATCH operation.
     • The request can be made to specific resource endpoints, such as Pods, Services, ConfigMaps, etc.
     • The request might look something like this for watching Pods:

       GET /api/v1/pods?watch=true
       

  2. Streamed Response:

     • Upon establishing the watch connection, the server responds with a stream of events related to the requested resource type.
     • The response typically starts with the initial state of the resource and then provides updates for any changes (additions, updates, and deletions).

  3. Event Types:

     • Each event received in the stream will have a type indicating the nature of the change:
       • ADDED: Indicates that a new resource has been created.
       • MODIFIED: Indicates that an existing resource has been updated.
       • DELETED: Indicates that a resource has been deleted.
     • Each event contains the relevant resource object, allowing the client to take action based on the changes.

  4. Connection Management:

     • The watch connection is long-lived. If the connection is lost or closed for any reason (e.g., network issues, server restarts), clients must be prepared to reconnect.
     • The client can re-establish the watch by sending another request to the API server, and it may include a resourceVersion parameter to continue watching from the last known state.

  5. Resource Versions:

     • Each change to a resource increments its resourceVersion, which is essential for maintaining the consistency of watch events.
     • Clients can use resourceVersion to resume watching from a specific point in time, avoiding missed events due to connection issues.

  6. Efficiency:

     • The watch mechanism is more efficient than continuous polling as it reduces the number of API calls by providing updates in real-time.
     • This mechanism allows applications to react promptly to changes in the Kubernetes cluster state without overwhelming the API server with requests.

Questions

If there are any uncertainties or questions, please don’t hesitate to reach out or ask for clarification.