Kubernetes application that collects, exposes and optionally uploads inventory data.
It runs in a loop every COLLECT_INTERNAL
and collects:
- Cluster information (versions, etc)
- Workload information (deployments, etc)
- Infrastructure information (cloud, region, zone, etc)
- Node information
- Storage information
- Secure Cloud Stack specific information (customer data, etc)
- Custom Resource information (CNI, specific operators)
For more information about what is collected, see k8s-inventory.
Configure the client (see Configuration below) and run the executable. It doesn't take any command line options or arguments:
k8s-inventory-client
k8s-inventory-client will try to detect if it's running inside a kubernetes
cluster. If not, it will try to configure a kubernetes client by using the
credentials and default context from ~/.kube/config
. This makes it possible to
run the client outside of a cluster, e.g. for development purposes.
While not strictly required, not gathering Secure Cloud Stack information kind of defeats the purpose of running the client at all.
Secure Cloud Stack Information is read from ConfigMap
-objects.
These objects must be created in the netic-metadata-system
Namespace
:
- General cluster information uses the first
ConfigMap
matching thenetic.dk/owned-by=operator
label - Tenant information uses all
ConfigMap
s matching thenetic.dk/owned-by=tenant
label
See dist/deployment/netic-metadata.yaml
for examples.
In order to collect the data, k8s-inventory-client needs permission to read
a wide array of resources. See dist/deployment/k8s-inventory-client.yaml
for a list of permissions.
Configuration is done using environment variables:
Variable Name | Description | Default |
---|---|---|
HTTP_PORT |
HTTP port to listen on for the inventory service | 8087 |
HTTP_PORT_META |
HTTP port to listen on for the metadata service | 8088 |
COLLECT_INTERNAL |
How often to collect | 1h |
LOG_LEVEL |
Logging level | info |
LOG_FORMATTER |
Log output formatter | json |
UPLOAD_INVENTORY |
Upload inventory | true |
SERVER_API_ENDPOINT |
HTTP URL to upload data to | http://localhost:8086/api/v1/inventory |
AUTH_ENABLED |
Enable/disable authentication | true |
TLS_CRT |
PEM Certificate file to use for authentication | /etc/certificates/tls.crt |
TLS_KEY |
PEM KEY file to use for authentication | /etc/certificates/tls.key |
SERVER_API_ENDPOINT |
HTTP URL to upload data to | http://localhost:8086/api/v1/inventory |
IMPERSONATE |
Kubernetes role to imporsonate |
COLLECT_INTERNAL
takes a values that can be parsed by
time.ParseDuration()
.
LOG_FORMATTER
can be set to one of:
- json
- text
LOG_LEVEL
can be set to one of:
- debug
- info
- warn
- error
- fatal
- panic
If you use a Secure Cloud Stack cluster, chances are k8s-inventory-client is already deployed.
However, if you need to deploy it yourself, you will need to:
- Create the
ConfigMap
s mentioned above - Create the Kubernetes resources:
- ServiceAccount
- ClusterRole
- ClusterRoleBinding
- Service
- Deployment
See kustomization.yaml
for a full example of deploying the client.
netic-metadata.yaml
creates the ConfigMap
s.
k8s-inventory-client.yaml
creates the other resources.
Typical adjustments:
- Set the
app.kubernetes.io/version
label to match the image version - Set the image tag to the version you want to deploy
- In the
Deployment
set environment variables accordingly - If using another port, set the
Service
ports
Use the supplied Makefile
.
make build
or make build2
builds the executable and places it in
bin/k8s-inventory-client
. build
forces rebuilding of packages and also runs
the linter. build2
does not.
make docker-build
and make docker-push
builds/tags/pushes the docker image.