packet-ccm
is the Kubernetes CCM implementation for Packet. Read more about the CCM in the official Kubernetes documentation.
At the current state of Kubernetes, running the CCM requires a few things. Please read through the requirements carefully as they are critical to running the CCM on a Kubernetes cluster.
Recommended versions of Packet CCM based on your Kubernetes version:
- Packet CCM version v0.0.4 supports Kubernetes version >=v1.10
- Packet CCM version v1.0.0 support Kubernetes version >=1.15.0
TL;DR
- Set kubernetes binary arguments correctly
- Get your Packet project and secret API token
- Deploy your Packet project and secret API token to your cluster
- Deploy the CCM
Control plane binaries in your cluster must start with the correct flags:
kubelet
: All kubelets in your cluster MUST set the flag--cloud-provider=external
. This must be done for every kubelet. Note that k3s sets its own CCM by default. If you want to use the CCM with k3s, you must disable the k3s CCM and enable this one, as--disable-cloud-controller --kubelet-arg cloud-provider=external
.kube-apiserver
andkube-controller-manager
must NOT set the flag--cloud-provider
. They then will use no cloud provider natively, leaving room for the Packet CCM.
WARNING: setting the kubelet flag --cloud-provider=external
will taint all nodes in a cluster with node.cloudprovider.kubernetes.io/uninitialized
.
The CCM itself will untaint those nodes when it initializes them.
Any pod that does not tolerate that taint will be unscheduled until the CCM is running.
By default, the kubelet will name nodes based on the node's hostname. Packet's device hostnames are set based on the name of the device. It is important that the Kubernetes node name matches the device name.
To run packet-ccm
, you need your Packet project ID and secret API key ID that your cluster is running in.
If you are already logged into the Packet portal, you can create one by clicking on your
profile in the upper right then "API keys".
To get your project ID click into the project that your cluster is under and select "project settings" from the header.
Under General you will see "Project ID". Once you have this information you will be able to fill in the config needed for the CCM.
Copy deploy/template/secret.yaml to someplace useful:
cp deploy/template/secret.yaml /tmp/secret.yaml
Replace the placeholder in the copy with your token. When you're done, the yaml
should look something like this:
apiVersion: v1
kind: Secret
metadata:
name: packet-cloud-config
namespace: kube-system
stringData:
cloud-sa.json: |
{
"apiKey": "abc123abc123abc123"
"projectID": "abc123abc123abc123"
}
Then apply the file via kubectl
, e.g.:
kubectl apply -f /tmp/secret.yaml`
You can confirm that the secret was created with the following:
$ kubectl -n kube-system get secrets packet-cloud-config
NAME TYPE DATA AGE
packet-cloud-config Opaque 1 2m
You can apply the rest of the CCM by using kubectl
to apply deploy/releases/<version>/deployment.yaml
, e.g:
kubectl apply -f deploy/releases/v1.0.0/deployment.yaml
By default, ccm does minimal logging, relying on the supporting infrastructure from kubernetes. However, it does support
optional additional logging levels via the --v=<level>
flag. In general:
--v=2
: log most function calls for devices and facilities, when relevant logging the returned values--v=3
: log additional data when logging returned values, usually entire go structs--v=5
: log every function call, including those called very frequently