Kubernetes PV ve PVC AccessModes Uyumu

Giriş

Şeklen şöyle

Açıklaması şöyle

ReadWriteOnce (RWO): This is the default access mode. It allows the PVC to be mounted as read-write by a single node in the cluster. This means that the PVC can be used by a single pod running on that node and is not available to other nodes in the cluster.

ReadOnlyMany (ROX): This access mode allows the PVC to be mounted as read-only by many nodes in the cluster. This means that the PVC can be used by multiple pods running on different nodes, but they can only read from it, not write to it.

ReadWriteMany (RWX): This access mode allows the PVC to be mounted as read-write by many nodes in the cluster. This means that the PVC can be used by multiple pods running on different nodes, and they can both read from and write to it.

ReadWriteOncePod: The ReadWriteOncePod storage class is a pre-defined storage class that can be used to create a persistent volume with ReadWriteOnce access mode that is intended to be used by a single pod. Kubernetes ensures that pod is the only pod across your whole cluster that can read that PVC or write to it.

Örnek

3 tane PV şöyle olsun. Hepsi hostPath kullanıyor. 

1. ReadOnlyMany

2. ReadWriteMany

3. ReadWriteOnce

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv-rox
spec:
  storageClassName: standard
  capacity:
    storage: 5Gi
  accessModes:
    - ReadOnlyMany
  hostPath:
    path: /data/my-pv-rox

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv-rwx
spec:
  storageClassName: standard
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  hostPath:
    path: /data/my-pv-rwx

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv-rwo
spec:
  storageClassName: standard
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /data/my-pv-rwo

Bunlarla uyumlu 3 tane PVC yaratmak için şöyle yaparız.  Hepsinin storageClassName ismi standard ve accessModes şöyle

1. ReadOnlyMany

2. ReadWriteMany

3. ReadWriteOnce

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc-rox
spec:
  storageClassName: standard
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 1Gi

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc-rwx
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc-rwo
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Common Pods Errors - Startup errors

Giriş

Bazı hatalar şöyle

1. ImagePullBackoff
2. ImageInspectError
3. ErrImagePull
4. ErrImageNeverPull
5. RegistryUnavailable
6. InvalidImageName

Ayrıca FailedScheduling de çok yaygın

Ne Yapmak Lazım

1. kubectl describe pod $POD_NAME | less ile duruma bakılabilir

2. Eğer bir şeyi değiştirip tekrar denemek istersek şöyle yaparız

kubectl edit pod $POD_NAME
# or 
kubectl edit deployment $DEPLOYMENT_NAME

# or if you just want to view the information
kubectl get deployment $DEPLOYMENT_NAME -oyaml

3. loglara bakabiliriz. Şöyle yaparız

kubectl logs $POD_NAME
kubectl logs $POD_NAME -c $CONTAINER_NAME

# or if you want to follow continuous output
kubectl logs -f $POD_NAME

# Another super useful debugging tool is the -p/--previous flag, 
# which you can use in the case that an instance keeps crashing/ 
# there was an unexpected restart.
kubectl logs -p $POD_NAME

ContainerCreating 

Açıklaması şöyle

Generally the pod will be stuck in states like ContainerCreating or if there’s an image issue you might see ImagePullBackoff , possibly indicating the image couldn’t be found or authenticated to.

ImagePullBackOff 

Açıklaması şöyle

This error means K8s is unable to pull the image for one of the containers in the Pod.

Common cause of the error could be one of the following,

1. The Image name is invalid
2. You specified non existing tag for the Image
4. The image that you are trying to pull belongs to a private registry and k8s does not have credentials to access it.

The first two cases can be solved by correcting the image name and tag.

For the last, you should add the credentials to your private registry in a Secret and reference it in your Pods.

FailedScheduling 

nodeSelector veya nodeAffinity kullanılıyorsak olabilir. 

Örnek

kubectl -n <namespace> describe pod <podname> çıktısı şöyledir

Warning FailedScheduling 118s (x26 over 7m43s) default-scheduler 0/53 nodes are available: 53 node(s) didn’t match Pod’s node affinity

kind: DaemonSet

Giriş

Açıklaması şöyle. Yani DaemonSet her worker node üzerinde çalışır

DaemonSets are great for running a single instance of an application on every node in the cluster. These are applications that need to be run on every node in the cluster. This could be things like logging or monitoring agents. For example, if you have a logging agent that you want to run on every node in your cluster, you could use a DaemonSet to make sure that there is an instance of the agent running on each node. This is useful because it ensures that the same instance of the application is running on each node, which can be important for tasks that require node-level access or coordination.

Örnek - Logging Agent

Şöyle yaparız

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: logging-agent-daemonset
spec:
  selector:
    matchLabels:
      app: logging-agent
  template:
    metadata:
      labels:
        app: logging-agent
    spec:
      containers:
      - name: logging-agent
        image: my-logging-agent-image:latest
        volumeMounts:
        - name: logs
          mountPath: /var/log
      volumes:
      - name: logs
        hostPath:
          path: /var/log