kubeconfig
file.kubeconfig
file and either download it into the projects directory or copy its content and paste it into a new file named kubeconfig.yaml
.kubectl
command-line interface to interact with our Kubernetes cluster.
kubeconfig
filekubeconfig.yaml
file is a configuration file that stores the information required for connecting to one or more Kubernetes clusters. This file is essential for using kubectl
, the CLI tool for interacting with Kubernetes clusters. The file contains various data types, such as cluster details, user credentials, and context information, which enable secure communication between your local machine and the Kubernetes API server.
kubeconfig.yaml
filekubeconfig
file, which you will find on Linode after you deploy the cluster.
apiVersion and kind
kubeconfig
files, the kind
is usually set to Config
.
clusters
users
contexts
Contexts
are combinations of clusters and users, along with an optional namespace. They define the environment in which kubectl
commands are run.
current-context
kubectl
commands. It should match one of the context names defined in the contexts
section.
kubeconfig
workskubectl
command, the tool looks for a kubeconfig
file in a default location, usually ~/.kube/config
, although you can specify a different file using the --kubeconfig
flag. kubectl
uses the current-context
to determine which cluster to connect to and which credentials to use for authentication.
kubeconfig.yaml
kubeconfig.yaml
file is crucial for effectively managing Kubernetes clusters, especially when dealing with multiple clusters or switching between user credentials.
Now, in your project’s directory, where the kubeconfig.yaml
file is, run:
KUBECONFIG
environment variable to point to the kubeconfig.yaml
file. This environment variable informs the kubectl
CLI to find the configuration file that contains all the necessary details for connecting to a Kubernetes cluster.
You can run the following commands to see some info:
ConfigMaps
and Secrets
, which can be mounted as files or exposed as environment variables.soos3d/addressbalance:latest
, contains all the code and dependencies needed to run our application.
At this point, let’s keep in mind that this app requires an Ethereum RPC node URL and port number as environment variables. Let’s use Chainstack to get an RPC node URL:
Get the RPC URL to use as an environment variable using the --env
flag. Now, in the terminal, run the following command:
kubectl run
is as follows:
kubectl run addressbalance
addressbalance
.
--image=soos3d/addressbalance:latest
latest
tag indicates that we want to use the most recent version of this image.
--port=80
--env="ETHEREUM_RPC_URL=YOUR_CHAINSTACK_ENDPOINT"
ETHEREUM_RPC_URL
in the container. The value for this variable is set to the Ethereum RPC URL. Environment variables are used for configuration settings that shouldn’t be hard-coded into the application.
--env="PORT=3333"
PORT
with the value 3333
. The application uses this to know which port to run on or listen to internally.
The --env
flags allow you to inject environment variables into your container, which can then be accessed by the application running inside it. This is useful for passing in configuration settings or other dynamic values your application needs to function correctly.
NAME
— the name of the pod, which in this case is addressbalance
.READY
— indicates the number of containers in the pod that are ready. 1/1
means one out of one container is ready.STATUS
— shows the current status of the pod. Running
means the pod has been successfully deployed and is running.RESTARTS
— indicates how many times the container within the pod has been restarted. A value of 0
means no restarts have occurred.AGE
— shows how long the pod has been running since its creation.describe
command to get more info; this will also show the environment where you can see if the environment variables are correctly set:
server_deployment.yaml
; note that you can name it however you want, then paste the following:
apiVersion: apps/v1
— specifies the API version to use for creating this deployment object.kind: Deployment
— indicates that the Kubernetes object being defined is a deployment.metadata
— contains metadata like the name (addressbalance
) and labels (app: addressbalance
) for the deployment.spec
— specifies the desired state of the deployment.
replicas: 4
— indicates that 4 replicas (instances) of the pod should be running.
selector
— defines how to identify the pods that belong to this deployment using the label app: addressbalance
.
template
— describes the pod template for the replicas.
metadata
— specifies the labels that should be applied to each pod created by this deployment.
spec
— describes the containers that should be part of each pod.
containers
— lists the containers to run within the pod.
name: addressbalance-container
— names the container.image: soos3d/chatgpt_server:latest
— specifies the container image to use.imagePullPolicy: Always
— ensures that the image is always pulled from the registry, even if it already exists locally.ports
— specifies that the container should listen on port 3333, the port set up for the server.env
— this section is used to define environment variables for the container. Each environment variable is represented as a key-value pair. In this example, two environment variables are set: ETHEREUM_RPC_URL
and PORT
. These variables can be accessed by the application running inside the container and are often used for configuration settings that should not be hard-coded.soos3d/addressbalance:latest
image and listening on port 3333. The deployment will manage the lifecycle of these pods, ensuring that 4 instances are always running. If any pod fails or is terminated, a new one will be created to maintain the desired state.
Run the deployment with this command:
kubectl get pods
will now show the 5 pods running, the 4 we just deployed, plus the first one deployed manually.
LoadBalancer
, the ports to forward, and other configurations specific to Linode’s load balancer.
Create a YAML file named server_loadbalance.yaml
and paste the following:
apiVersion: v1
v1
version is the stable version for service objects in Kubernetes.
kind: Service
metadata
name: addressbalance-service
— the name of the service. This is how you will refer to the service within your cluster.annotations
— annotations are arbitrary metadata you can use for your purposes but are not used to identify the object.
service.beta.kubernetes.io/linode-loadbalancer-throttle
: "4"
— this is a Linode-specific annotation that controls the throttle settings for the load balancer. This sets the client connection throttle to limit the number of new connections per second from the same client IP to 4 and can go up to 20. This is useful for controlling the rate at which a single client can make new connections to your service, which can be particularly important for mitigating certain types of denial-of-service attacks or for managing resources effectively.labels
— key-value pairs that are used to identify the service.
app: addressbalance
— this label specifies that the service is part of the addressbalance
application.spec
type: LoadBalancer
— this specifies that the service will be exposed via a load balancer.
ports
— this array specifies the network ports on which the service will accept traffic.
name: http
— the name of the port (for reference).protocol: TCP
— the network protocol to use (TCP/UDP).port: 80
— the port on which the service will listen for incoming traffic.targetPort: 3333
— the port on the pod to which traffic will be forwarded.selector
— this specifies the labels that must be present on a pod to receive traffic from this service.
app: addressbalance
— only pods with this label will receive traffic from this service.sessionAffinity: None
— this specifies that the service will not try to send all requests from a single client to the same pod.