k8s-node-collector

K8s-node-collector is an open source application that periodically analyzes the open ports of the our cluster nodes in kubernetes and saves them in a report directory in the most convenient path.

Table of content

• 1 Getting Started
  • About the Project
  • Prerequisites
• 2 Create ServiceAccount | RBAC
• 3 Persistent Storage
• 4 Docker container
• 5 Script collector.sh
• 6 Run and configure k8s-node-collector
  • Values
• 7 License

Getting Started ⭐️

About the project 💡

In order to use k8s-node-report this project uses the k8s-node-collector docker image as a container resource that will run periodically through a kubernetes CronJob manifest. When the Cronjob starts it will deploy the necessary jobs with their corresponding pods that will collect the information from the nodes. Follow this documentation for implementation.

Prerequisites 🧾

• This project assumes that you already have a cluster of kubernetes running with one and multiple worker nodes. It can be in any public / private cloud or on-premises.
• It also assumes that there's a storage class configured in the cluster that will later be used to generate volumes to store the reports.

Create ServiceAccount | RBAC 🔧

If we want to fetch information from the workes nodes we need our pods to be able to authenticate and make calls to the k8s API. To achive this we will:

1. Create a k8s role with required permissions
2. Create a k8s service account
3. Create a role-binding with role and serviceaccount created above

kubectl apply -f sa-rolebinding.yaml

The pods our CronJob generates will use this service account to access k8s api.

❗️ It is recommended for a production environment to generate a service account with only the permissions our resorces will use [create, list, update, watch ....] in this example we will use admin permissions. More about Roles and ClusterRoles: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole

Persistent Storage 💾

The reports should be persistent over time and accessible to other resources if necessary. To do this we are going to create a PVC-type resource in k8s, which will later be used by our persist volume (PV). As mentioned in the prerequisites, it is assumed that a Storage Class already exists in our cluster. This example is used with one called gp2 but may need to be modified in each case.

kubectl apply -f claim.yaml

Docker container 🐳

The k8s-node-collector solution has a docker image that contains several tools already packaged that the CronJob will use, such as as wget to download the collector.sh (script that collects open ports of nodes) or kubectl (necessary for make calls to the k8s api)

https://hub.docker.com/r/alvarolg/k8s-node-collector

Script collector.sh 🔬

The collector.sh script has two main parts:

• When the k8s-node-collector Job is called by the CronJob, a main pod will run, which will automatically download the most up-to-date version of the collector.sh . It will use a list of all available nodes in our cluster and generate a secondary pod manifest for each node.

• Subsequently, it launches a secondary pod in each of the nodes of our cluster. This secondary pod will run netstat command in the same network namespaces of the host. It will save the information in our report file inside the PV and delete itself when completed. This action will be done one by one for each of the nodes of our cluster until we have information of all of them.

❗️ So the secondary pod can use the nodes network namespace it includes declared the HostNetwork as true this can be a security risk, so bear in mind this before running this in a productive enviroment. More information regarding Security Policies and HostNamespaces: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#host-namespaces

Run and configure k8s-node-collector

As mentioned, when running k8s-node-collector it is preferable to use a Cronjob manifest that allows scheduling for the moment when the reports will be generated. However, any other resource type such as jobs, deployments or pods could be configured equally. (For this example it'll generate the report every night at 3:00 AM)

kubectl apply -f cronjob.yaml

Values

• The pod will use the SA created in the point 2
• The environment variable PATH_REPORTS will be where the generated report will be saved. It is customizable in each case. If there is no value it will simply be omitted
• No history of Jobs is needed so the success/failed JobsHistoryLimit is added .
• The pod will reboot in case of failure.

License

Distributed under the GNU General Public License v3.0 License. See LICENSE for more information.