Kubernetes Integration #2
Description
@claude let's plan how we can deploy this bot to our k8s cluster to gke autopilot (the context is set) i want to run one container for each user who is interacting with the
bot. in that container, we will run the slack bot. if the container is waiting for user input for more than 5 minutes, it will be killed. for each user, we will create
a repository on github with the name matching with their username. the repository will be pulled into the container at start and the session will be run on that
repository content
Plan
Observations
The current PeerBot is a single-container Slack bot that handles all users in a shared environment. The requirement is to transform this into a Kubernetes-based architecture where each user gets their own container with a 5-minute timeout and user-specific GitHub repository. The existing codebase has solid foundations with session management, GitHub integration, and configurable working directories that can be adapted for this new architecture.
Approach
I'll implement a dispatcher-worker pattern where a central dispatcher pod listens to Slack events and spawns ephemeral worker pods for each user. Each worker pod will have its own GitHub repository, isolated workspace, and 5-minute timeout. This approach balances simplicity with the requirement for per-user isolation while leveraging existing code structures.
Key Design Decisions:
Dispatcher Pattern: One long-lived dispatcher + ephemeral user pods (avoids Slack socket connection limits)
Job-based Workers: Use Kubernetes Jobs with TTL for automatic cleanup
GitHub Repository Strategy: Create user-named repositories in the PeerBot-Community organization
Workspace Isolation: Each pod gets its own /workspace/{username} directory
Timeout Strategy: Combination of Kubernetes TTL and internal JavaScript watchdog
Reasoning
I explored the entire codebase to understand the current architecture. I examined the session management system, GitHub integration, working directory management, Slack integration, configuration system, and Docker setup. I found that the bot currently runs as a single container with in-memory session management and has good foundations for GitHub integration and configurable workspaces. There are no existing Kubernetes configurations, so I need to design the entire K8s architecture from scratch.
I don't need different environments, one bot one workload in kubernetes. For persistency when the container is exiting write the data into GCS bucket that is provisioned for the project. The bucket name is peerbot-conversations-prod. I don't need an extra database.