K3s Kubernetes Infrastructure Generation Prompt

This document contains the prompt that can be used to regenerate the entire K3s Kubernetes infrastructure project based on the PlantUML diagrams provided in this directory.

Prompt for Project Generation

Please generate a complete Terraform project for deploying a K3s Kubernetes cluster based on the following PlantUML diagrams:

1. The activity diagram (k3s_infrastructure_activity_diagram.puml) shows the workflow and sequence of operations for setting up the K3s infrastructure.
2. The component diagram (k3s_component_diagram.puml) illustrates the main components and their relationships.
3. The sequence diagram (k3s_sequence_diagram.puml) details the interaction between different components during deployment.
4. The deployment diagram (k3s_deployment_diagram.puml) shows the physical architecture of the Kubernetes cluster.
5. The class diagram (k3s_class_diagram.puml) depicts the relationships between Terraform resources.

Based on these diagrams, create a complete Terraform project with the following structure:

- terraform/
  - modules/
    - k3s-install/
      - main.tf (K3s installation logic)
      - variables.tf (Module variables)
      - outputs.tf (Module outputs)
  - infra/
    - dev/
      - main.tf (Main entry point)
      - variables.tf (Variable definitions)
      - terraform.tfvars (Variable values)
      - env.tf (Environment file handling)
      - providers.tf (Provider configurations)
      - .env (Environment variables - empty template)

The project should implement the following functionality:
1. Setup SSH configuration for secure connections to server and worker nodes
2. Install K3s server on the main node
3. Retrieve kubeconfig and node token from the server
4. Copy the node token to worker nodes
5. Install K3s agents on worker nodes
6. Provide proper cleanup/uninstallation on terraform destroy
7. Handle any potential errors gracefully

Use only null and local providers for this infrastructure. All operations should be performed using SSH connections and local-exec/remote-exec provisioners.

Please implement each file with complete, working code that follows Terraform best practices.

IMPORTANT CONSIDERATIONS:
1. Avoid duplicate local value declarations across files. If you create local values in env.tf, don't create variables with the same name in main.tf.
2. For destroy-time provisioners, remember that they can only reference attributes of the related resource using 'self', 'count.index', or 'each.key'. Store any paths or values needed during destroy in the resource's triggers, and then reference them using self.triggers.<name>.
3. Ensure proper dependency management between resources to maintain correct deployment sequence.
4. Use resource-specific variables in destroy provisioners rather than module-level locals.
5. Implement validation for input variables where appropriate.

Diagram Formatting Guidelines

When interpreting the PlantUML diagrams, note that they follow specific formatting conventions to clearly represent infrastructure components and their relationships.

Activity Diagram Formatting

Activity diagrams use a structured format with header separators (====) and detail separators (----):

:Activity Name
====
parameter1=value1
parameter2=value2
parameter3=value3
----
Additional context or explanation;

The parameters section contains key configuration values, and variables are properly escaped with single quotes when they contain special characters (like Terraform variables):

Example: local_path='${kubeconfig_path}' instead of local_path=${kubeconfig_path}

Component Diagram Formatting

Component diagrams use the C4 model approach with consistent tagging:

Component(id, "Name", "Technology", "Description", $tags="tag")

Sequence Diagram Formatting

Sequence diagrams show detailed interactions with parameters and context similar to activity diagrams, using the same header/detail separator pattern.

Deployment Diagram Formatting

Deployment diagrams use consistent stereotypes (<>, <>, <>) and clear connection representations.

Class Diagram Formatting

Class diagrams represent Terraform resources as UML classes with proper property types and relationships.

Modifying the Infrastructure

To modify the infrastructure, you can:

Edit the PlantUML diagrams to reflect your desired changes
Provide a prompt like the following:

Based on the modified PlantUML diagram [diagram_name.puml], please update the corresponding Terraform files to implement these changes:

[List specific changes here]

Ensure that the changes maintain the overall integrity of the infrastructure and follow Terraform best practices.

Additional Considerations

The diagrams contain detailed comments and notes that explain the functionality and purpose of each component
The activity diagram shows the exact flow of operations needed for proper deployment
The class diagram maps directly to Terraform resources and their relationships
The sequence diagram provides timing information critical for understanding dependencies

By following these diagrams, you can generate a fully functional Terraform project for deploying a K3s Kubernetes cluster on any compatible infrastructure.

5.2 KiB Raw Blame History