2 min read
When building an application we might like to update a different repository to update the app's versions number. For example, if we build a docker containter using a github action we might want to update the tag on the helm repository. This is by default restricted: a github action only has access to it's own repository but we can create a PAT to workaround this problem
29/10/2021
Read more...2 min read
The cluster autoscaler takes into consideration several factors when it chooses a node to remove (evicting it's Pods)
28/10/2021
Read more...3 min read
Sometimes we need a way of telling using a HTTP endpoint the readiness of the service but the service does not provide any of this: For example, a MySQL replica that we need to get in and out of the pool depending on how lagged it is, or a worker node that we want to remove from that pool depending on it's CPU usage...
If we have a command that will tell us whether the service is ready to accept connections, we can use healthcheckd to create a HTTP endpoint to publish it.
27/10/2021
Read more...2 min read
We have 3 API endpoints available to check the current status of the API server. One of them, the healthz endpoint is being deprecated (since Kubernetes v1.16) since the other two (livez and readyz) being more specific
26/10/2021
Read more...3 min read
When we don't have the Pod's resources correctly configured we might face the need of moving a Pod to a different node. Although we could change the nodeSelector or adjust the resources to that it gets scheduled on a different node, it might urge us to fix an issue. To do so we can use kubectl drain
At the end of the day what we want it really is "drain the node of that kind of Pods". As kind of by product the node ends up being cordoned so we are sure the Pod won't be scheduled again on the same node.
25/10/2021
Read more...2 min read
If we try to use less on an application with colored output it will get messy like this:
$ terraform plan | less
(...)
Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
ESC[33m~ESC[0m update in-place
ESC[0m
Terraform will perform the following actions:
ESC[1m # module.spinnaker.kubernetes_default_service_account.default_saESC[0m will be updated in-placeESC[0mESC[0m
ESC[0m ESC[33m~ESC[0mESC[0m resource "kubernetes_default_service_account" "default_sa" {
ESC[1mESC[0midESC[0mESC[0m = "spinnaker-green/default"
ESC[90m# (2 unchanged attributes hidden)ESC[0mESC[0m
ESC[31m-ESC[0m ESC[0msecret {
ESC[31m-ESC[0m ESC[0mESC[1mESC[0mnameESC[0mESC[0m = "default-token-m2z4q" ESC[90m->ESC[0m ESC[0mESC[90mnullESC[0mESC[0m
}
ESC[90m# (1 unchanged block hidden)ESC[0mESC[0m
}
ESC[0mESC[1mPlan:ESC[0m 0 to add, 1 to change, 0 to destroy.
ESC[0mESC[90m
(...)
22/10/2021
Read more...2 min read
Update 10/02/2020: The new version 4.0 of the AWS provider have been released. At this point, all AWS provider plural data sources (like the aws_security_groups) that return an array of results will now return an empty list if zero results are found.
Prior to that, if when trying to use the aws_security_groups data source if the tags did not match any SecurityGroup, terraform would have returned an error instead of an empty list:
data "aws_security_groups" "eks-pod" {
tags = {
"NotAnActualTag" = "WontMatchAnything"
}
}
21/10/2021
Read more...1 min read
If we allow a pod to interact with the cluster's API, as long as we have kubectl installed on the container, we don't really need to worry about the kubeconfig file. Although some applications might complain is they don't find it, so we might need to create a fake kubeconfig just to make them happy
20/10/2021
Read more...2 min read
If we want to append a value to a list, using read we will see it like a regular value separated by spaces:
$ vault read -field=bound_iam_role_arn auth/aws-ec2/role/pet2cattle-role
[arn:aws:iam::111111111111:role/pet2cattle-role arn:aws:iam::222222222222:role/pet2cattle-role]
But the we cannot just copy and paste the value, otherwise we would be setting it as a single string
19/10/2021
Read more...2 min read
If we need to investigate why a container keeps restarting, a good place to start is taking a look at the logs when it crashes. Since Kubernetes will automatically restart a failed container, if we use kubectl logs we will get the logs of the restarted container instead of the one that have crashed:
$ kubectl logs ampa-7d98c84675-dpzjw -c ampa
[2021-10-15 14:20:41 +0000] [1] [INFO] Starting gunicorn 20.0.4
[2021-10-15 14:20:41 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2021-10-15 14:20:41 +0000] [1] [INFO] Using worker: sync
[2021-10-15 14:20:41 +0000] [8] [INFO] Booting worker with pid: 8
How can we retrieve the logs of the previous container?
18/10/2021
Read more...