삶은 개발

한국어 카테고리

AWS EC2 Kubernetes WordPress Hosting – Abandoned

Official website resource – https://kubernetes.io/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

WordPress uses a MySQL database, and the information must be stored in a persistent space. The persistent spaces provided by Kubernetes are identified and utilized.

#1. The Relationship Between Kubernetes PersistentVolume and PersistentVolumeClaim

It’s good to use persistent storage, but the idea of using it for backups or recycling came first. However, there is no existing method for setting a static or direct relationship between PV (PersistentVolume) and PVC (PersistentVolumeClaim) for such functionalities.

While utilizing persistence, operational settings are not pursued. It’s better to move to a method of backing up and restoring from the service instead.

If that’s the conclusion, then create suitable PVs and let Kubernetes use them as needed.

#2. Explaining the Relationship Between PV (PersistentVolume) and PVC (PersistentVolumeClaim)

1. Relationship Setup

In Kubernetes, PersistentVolume (PV) and PersistentVolumeClaim (PVC) are critical concepts for permanently storing and using data.

  1. PersistentVolume (PV):
    • A PersistentVolume represents a storage volume available in the cluster. It can be network storage (NFS, iSCSI, etc.) or internal cluster storage (host path, local disk, etc.).
    • PVs are created and managed by cluster administrators. Details such as storage class, capacity, and access modes are defined.
    • PVs are shared across the cluster, and multiple PVCs can simultaneously request the same PV.
  2. PersistentVolumeClaim (PVC):
    • A PersistentVolumeClaim is how a Pod requests a PV to use. A PVC specifies the size and access mode of the storage a Pod will use.
    • PVCs are typically created and managed within a namespace, meaning they can request a PV for use by Pods within that namespace only.
    • Using a PVC allows Pods to request access to a storage class defined by the cluster administrator without knowing the details of the storage.

The relationship between PV and PVC is as follows:

  • A PVC requests and uses a PV. When a PVC is created, Kubernetes looks for a PV that matches the requirements of the PVC. If no matching PV is found, the PVC remains pending.
  • A PV can be requested by multiple PVCs, but a PVC can request only one PV at a time. A PV can be bound to only one PVC at a time.
  • The binding between PVC and PV can be static or dynamic. Static binding involves the cluster administrator manually mapping a PVC to a PV, while dynamic binding uses a StorageClass to dynamically allocate a PV that matches the storage class requested by the PVC.

Using a PVC involves the following steps:

  1. Write a PVC definition: Create a YAML file defining the PVC. This file includes the requested storage size, access modes, and storage class.
  2. Create the PVC: Use the kubectl apply command to create the PVC. Kubernetes then finds or assigns the requested storage.
  3. Use the PVC: Specify the PVC in the volume section of a Pod to allow the Pod access to the storage defined by the PVC.

Through this process, a PVC allows a Pod to access persistent storage.

2. Selection Method

If multiple PersistentVolumes (PVs) with the same specs exist, Kubernetes allows a PersistentVolumeClaim (PVC) to select a previously used PV. This continues until a PV that matches the requested storage class and requirements of the PVC is found.

Typically, a PVC specifies a storage class and capacity to request a PV. Based on this information, Kubernetes selects a PV that matches the specs requested by the PVC. If multiple PVs with the same specs exist, Kubernetes selects a PV as follows:

  1. Select a matching PV: If there are multiple PVs that match the specs requested by the PVC, Kubernetes finds the best match. This occurs when the requested capacity and access modes of the PVC exactly match those of a PV.
  2. Select the most recently used matching PV: If there are multiple matching PVs and all are equivalent, Kubernetes selects the PV that the PVC was previously bound to. This is useful when a PVC wants to maintain a previously used PV.

To select a previously used PV, you can use the following methods:

  • Recreate the same PVC without deleting it. In this case, Kubernetes selects and binds the previously used PV.
  • Use labels or annotations in the PVC to guide matching to a specific PV. This allows Kubernetes to prefer a specific PV.

In summary, even if there are multiple PVs with the same specs, Kubernetes supports the selection of a previously used PV by a PVC.

3. Not Recoverable After Deletion

If a PV is deleted, the PVC that requested that PV cannot be reassigned to it. When a PV is deleted, Kubernetes releases the PVC bound to that PV, and the PVC goes into a pending state. Therefore, to reassign the PVC to a PV, a new PV must be created or an existing PV must be used.

The method to assign a new PV to a PVC is as follows:

  1. Create a new PV: Create a new PV with the same specs as the previously deleted PV. For this, the storage class, capacity, and access modes of the new PV must be specified to match those of the previously deleted PV.
  2. Modify the PVC: Modify the PVC’s YAML file to reference the new PV. Update the spec.volumeName field of the PVC to the name of the new PV or use a matching label selector to recreate the PVC.
  3. Recreate the PVC: Recreate the PVC to be assigned to the new PV. Delete the PVC and create a new one with the previously set specs. Kubernetes will assign the new PV and bind the PVC.

This allows the PVC to be reassigned to a new PV. However, to reassign a previously used PV, a new PV must be created, and the PVC must be modified or recreated instead of restoring or reverting the deleted PV.

#3. PV Settings

apiVersion: v1
kind: PersistentVolume
metadata:
  name: wp-pv-com
  labels:
    type: local
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/wordpress/data-com/pv0001"
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv-com
  labels:
    type: local
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/wordpress/data-com/pv0002"

#4. Tried all settings, but felt like a sudden stop though it took two days….

Basically, kubelet standalone couldn’t host services like service load balancers and deployments. Pods were launched successfully.

First, to identify the script’s issues, I tested the yaml file locally on Mac using minikube, and there were no problems.

Seeming like an issue with Kubelet standalone, I also built an Ec2 cluster. 6443 connection refused needs to be resolved, and assigning workers requires a lot of work.

Since using more than two EC2s, saving costs is challenging, and a lot of time has already been spent.

Others say it works, but my conclusion is this:

Kubelet standalone only runs pods. Persistent Volume and such do not work. I will give up.

I will stop here and give up If kube is the problem, let’s try docker compose….

The next blog will be about configuration with docker compose.
aws-ec2-ubuntu-에서-mariadb-설치

That’s all for today.

Addition: Ultimately, the free tier 1GB RAM does not meet the Kubernetes 2GB RAM requirements. This part is also challenging even with docker, which is used together with kubelet standalone.

Giving up

포기

전체 과정 블로그 /aws-ec2-mariadb-환경-설정