CKA Notes

cka-notes.md

1. ETCD Backup and Restore

Backup:

To backup an etcd cluster, you can use the etcdctl snapshot save command.

ETCDCTL_API=3 etcdctl snapshot save backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/path/to/cacert.pem \
  --cert=/path/to/cert.pem \
  --key=/path/to/key.pem

• backup.db: This is the name of the backup file that will be created.
• --endpoints: Specifies the etcd endpoint.
• --cacert, --cert, and --key: These are paths to the TLS certificates if your etcd cluster is using TLS for communication.

Restore:

To restore an etcd snapshot, you can use the etcdctl snapshot restore command.

ETCDCTL_API=3 etcdctl snapshot restore backup.db \
  --name m1 \
  --initial-cluster m1=https://10.0.0.1:2380 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-advertise-peer-urls https://10.0.0.1:2380 \
  --data-dir /path/to/new/data-dir

• backup.db: This is the name of the backup file to be restored.
• --name: The name of this member in the initial cluster.
• --initial-cluster: The initial cluster configuration for the restore. This defines how the cluster should be configured after the restore.
• --initial-cluster-token: The cluster token.
• --initial-advertise-peer-urls: List of this member's peer URLs to advertise to the rest of the cluster.
• --data-dir: Path to the data directory.

Note that when you restore, you typically need to restore to a new cluster configuration. The restored etcd node will start with a new cluster configuration and all members will need to join as new members.

It's important to regularly test backups by restoring them in a sandbox environment to ensure data integrity and the effectiveness of the backup and restore process.

Lastly, always check the official etcd documentation or etcdctl help command for any updates or changes related to backup and restore commands.

---

Kubernetes RBAC (Role-Based Access Control) Short Note:

1. RBAC Components:

• Roles and ClusterRoles: Define what actions (verbs) can be performed on which resources (resources) and in which namespaces (for Roles).
• RoleBindings and ClusterRoleBindings: Bind a Role or ClusterRole to a set of users, groups, or service accounts.

2. Role:

• Namespace scoped.
• Dictates what actions can be performed on which resources within a namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-name
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["list", "create", "delete"]

3. ClusterRole:

• Cluster scoped.
• Can be used across namespaces and can also grant access to cluster-scoped resources (e.g., nodes).

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterrole-name
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["list"]

4. RoleBinding:

• Grants the permissions defined in a Role within a specific namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: rolebinding-name
  namespace: default
subjects:
- kind: User
  name: username
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: role-name
  apiGroup: rbac.authorization.k8s.io

5. ClusterRoleBinding:

• Grants the permissions defined in a ClusterRole across the entire cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: clusterrolebinding-name
subjects:
- kind: User
  name: username
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: clusterrole-name
  apiGroup: rbac.authorization.k8s.io

---

Key Points on Roles vs. ClusterRoles:

1. Scope:

   • Roles: Namespace-scoped. Permissions are applicable only within a specific namespace.
   • ClusterRoles: Cluster-scoped. Permissions can be applied cluster-wide or to specific namespaces.

2. Binding:

   • Roles: Used with RoleBindings to grant permissions within a specific namespace.
   • ClusterRoles: Used with ClusterRoleBindings to grant permissions cluster-wide. They can also be used with RoleBindings to grant the same permissions within a specific namespace.

3. Common Use Cases:

   • Roles: Granting permissions to resources (e.g., pods, services) within a namespace.
   • ClusterRoles: Granting permissions to cluster-scoped resources (e.g., nodes), or granting the same permissions across multiple namespaces.

4. Reusability:

   • Roles: Must be defined separately for each namespace where you want the permissions.
   • ClusterRoles: Can be defined once and reused across multiple namespaces or the entire cluster.

5. Binding to Users:

   • Both can be bound to users, service accounts, or groups, but the scope of the effect depends on whether a RoleBinding or ClusterRoleBinding is used.

6. Aggregation:

   • ClusterRoles support aggregation, allowing you to create composite roles based on label selection.

7. Best Practice:

   • Use Roles and RoleBindings for permissions that should be isolated to a single namespace.
   • Use ClusterRoles and ClusterRoleBindings for cluster-wide permissions or when you want to reuse the same set of permissions across multiple namespaces.

---

Key Points on Roles vs. ClusterRoles:

...

Creation with kubectl create:

1. Roles:

   kubectl create role <role-name> --verb=<verb> --resource=<resource> -n <namespace>

   Example:

   kubectl create role pod-reader --verb=get --verb=list --resource=pods -n default

2. ClusterRoles:

   kubectl create clusterrole <clusterrole-name> --verb=<verb> --resource=<resource>

   Example:

   kubectl create clusterrole node-reader --verb=get --verb=list --resource=nodes

3. RoleBindings:

   kubectl create rolebinding <rolebinding-name> --role=<role-name> --user=<user-name> -n <namespace>

   Example:

   kubectl create rolebinding pod-reader-binding --role=pod-reader --user=john -n default

4. ClusterRoleBindings:

   kubectl create clusterrolebinding <clusterrolebinding-name> --clusterrole=<clusterrole-name> --user=<user-name>

   Example:

   kubectl create clusterrolebinding node-reader-binding --clusterrole=node-reader --user=john

Note: The above commands are basic examples. You can use the --group or --serviceaccount flags instead of --user for binding to groups or service accounts, respectively. Also, the --verb and --resource flags can accept comma-separated lists if multiple verbs or resources need to be specified.

---

Kubernetes Service Accounts: Key Points

Service accounts are used in Kubernetes to provide an identity for processes that run in a Pod. They are tied to a namespace and are used primarily for managing authentication within the cluster.

Creation

To create a new service account:

kubectl create serviceaccount <serviceaccount-name> -n <namespace>

Example:

kubectl create serviceaccount my-serviceaccount -n default

Service Account Tokens

• When you create a service account, a token is automatically generated and associated with it. This token can be used for in-cluster authentication.
• The token is stored as a secret in the namespace.

To get the secret name associated with a service account:

kubectl get serviceaccount <serviceaccount-name> -n <namespace> -o=jsonpath='{.secrets[0].name}'

Example:

kubectl get serviceaccount my-serviceaccount -n default -o=jsonpath='{.secrets[0].name}'

Mounting Service Accounts to Pods

• By default, the default service account of a namespace is automatically attached to all pods running in that namespace.
• You can specify a different service account using the serviceAccountName field in the pod spec.

Example pod spec with a service account:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-serviceaccount
  containers:
  - name: my-container
    image: my-image

Key Points

1. Service accounts are namespaced.
2. Use service accounts for in-cluster processes that need to communicate with the Kubernetes API.
3. Avoid using the default service account token in pods for security reasons; instead, create dedicated service accounts.
4. Role-based access can be granted to a service account using RoleBindings or ClusterRoleBindings.

---