Google Cloud에서 Kubernetes 엔진과 클라우드 SQL을 사용하여 Wordpress 등 상태 애플리케이션을 적절히 확장

인터넷에는 Kubernetes에서 Wordpress를 실행하는 방법을 보여 주는 예가 많다.이 예의 주요 문제는 포드 하나만으로wordpress를 실행할 수 없다는 것이다.
그래서 내가 직면한 문제는 고도로 확장 가능한wordpress 설정이 필요하다는 것이다. 이것이 바로 내가 생각한 것이다.

상태 있는 응용 프로그램을 확장하는 것이 왜 이렇게 어렵습니까?

이 프로그램들은 CD에 직접 쓰는데, 대부분의 경우 그것을 막을 수 없다.이것은 특정 플러그인 시스템을 사용하는 PHP 기반 응용 프로그램에서 자주 나타난다.따라서 파일은 특정한 유형의 저장소에 저장할 수 없고 응용 프로그램의 파일 시스템에 저장해야 한다.
지금은 비슷한 것을 말할 수 있지만, 클라우드 저장소에 쓸 수 있는 무상태 플러그인 https://de.wordpress.org/plugins/wp-stateless/ 이 있다.네, 이것은 정말입니다. 그러나 플러그인이나 파일을 저장하지 않습니다. 일부 플러그인은 그곳의 폴더에 직접 쓰일 수 있습니다. (불행히도 이런 상황이 발생했지만 사실입니다)

어떡하지?

우리는 확장 가능한 데이터베이스가 필요하고, 응용 프로그램과 응용 프로그램 자체에 사용할 공유 파일 라이브러리가 필요합니다.
시간을 줄이기 위해서, 우리는 미리 정의된 Wordpress Docker 이미지만 사용할 것입니다. 이 Docker 파일에 필요한 추가 내용을 만들려고 시도해야 하지만.그것들을 기초로 삼아라, 그러나 너의 필요까지 확장해야 한다.
그래서 우리는 공유 CD가 필요하다. 여기서 우리는 첫 번째 문제에 부딪혔다.우리 Kubernetes 집단에 ReadWriteMany 볼륨이 필요하면 문제가 시작됩니다.클라우드 공급자는 이 기능을 가지고 있지 않다.
검사하는 경우 the Kubernetes documentation
GCEPersistantDsik, AzureDisk 및 AWSElasticBlockStore는 우리가 필요로 하는 기능을 지원하지 않습니다.
Goolge Cloud의 CloudFileStore나 AzureFile 같은 옵션이 있지만, 우리의 사례에 있어서는 매우 비싸고 크다. (우리의 Wordpress를 저장하기 위해 1TB가 필요하지 않습니다.)

NFS 구조

그러나 우리가 이 명단을 보았을 때, 우리는 구세주: NFS의 구조를 보았다.NFS에 연결할 ReadWriteOnce 스토리지가 있는 유일한 옵션을 만듭니다.따라서 지역 간에 공유할 수 있는 이상적인 저장 클래스가 필요합니다.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
 name: regionalpd-storageclass
provisioner: kubernetes.io/gce-pd
parameters:
 type: pd-standard
 replication-type: regional-pd
 zones: europe-west3-b, europe-west3-c

우리는 대량 클레임을 만들어야 한다

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: nfs
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: ""
  volumeName: nfs

이제 NFS를 만듭니다.

apiVersion: v1
kind: Service
metadata:
 name: nfs-server
spec:
 clusterIP: 10.3.240.20
 ports:
   - name: nfs
     port: 2049
   - name: mountd
     port: 20048
   - name: rpcbind
     port: 111
 selector:
   role: nfs-server

이제 NFS 자체를 추가합니다.좋습니다. 우리는 미리 정의된 서비스를 사용할 수 있습니다.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: nfs-server
spec:
 replicas: 1
 selector:
   matchLabels:
     role: nfs-server
 template:
   metadata:
     labels:
       role: nfs-server
   spec:
     containers:
       - name: nfs-server
         image: gcr.io/google_containers/volume-nfs:0.8
         ports:
           - name: nfs
             containerPort: 2049
           - name: mountd
             containerPort: 20048
           - name: rpcbind
             containerPort: 111
         securityContext:
           privileged: true
         volumeMounts:
           - mountPath: /exports
             name: nfs
     volumes:
       - name: nfs
         gcePersistentDisk:
           pdName: nfs
           fsType: ext4

CloudSQL이 안전하고 아름답습니다.

알겠습니다. 정적 데이터에 사용할 실행 NFS가 있습니다.그래서 다음 중요한 단계는 클라우드 SQL을 연결하는 것이다.클라우드 SQL Mysql을 설치했다고 가정하십시오.당신은 어떻게 당신의 콩꼬투리를 그것에 연결합니까?
우리는 용기의 사이드카로 SQL 에이전트를 사용합니다.이렇게 하는 장점은 우리의 MySQL이 공개되지 않아서localhost를 사용할 수 있다는 것이다.너무 좋잖아, 그렇지 않아?
먼저 활성화해야 합니다Cloud SQL Admin API
클라우드 SQL에 실제로 액세스하려면 service account 을 만들어야 합니다.
여기서 우리는 클라우드 SQL > 클라우드 SQL 클라이언트의 권한을 가진 새로운 캐릭터를 만들었습니다
SQL 인스턴스에 액세스하는 데 필요한 개인 키를 다운로드합니다.
현재 데이터베이스 사용자를 만듭니다. 만약 당신이 아직 이렇게 하지 않았다면

gcloud sql users create [DBUSER] --host=% --instance=[INSTANCE_NAME] --password=[PASSWORD]

우리는 실례적인 명칭이 필요하다. 간단하다.

gcloud sql instances describe [INSTANCE_NAME]

또는 webinterface에서 찾을 수 있습니다.

이제 Kubernetes 인스턴스에 자격 증명을 저장합니다.

kubectl create secret generic cloudsql-instance-credentials \
    --from-file=credentials.json=[PROXY_KEY_FILE_PATH]
kubectl create secret generic cloudsql-db-credentials \
    --from-literal=username=[DBUSER] --from-literal=password=[PASSWORD]

그럼, 우리는 우리의 Wordpress를 설치할 준비가 되어 있지 않습니까?

먼저 서비스를 만듭니다.

apiVersion: v1
kind: Service
metadata:
 name: wlp-service
 labels:
   app: wlp-service
spec:
 type: LoadBalancer
 sessionAffinity: ClientIP
 ports:
   - port: 443
     targetPort: 443
     name: https
   - port: 80
     targetPort: 80
     name: http
 selector:
   app: wordpress

자, 이제 우리는 서비스를 시작하고 운행 중이며, 유일하게 부족한 것은 기중기 자체입니다.
우리가 그것을 좀 분리하자, 이렇게 하면 내가 설명할 수 있다

apiVersion: apps/v1
kind: Deployment
metadata:
 name: wordpress
 labels:
   app: wordpress
spec:
 replicas: 2
 strategy:
   type: RollingUpdate
 selector:
   matchLabels:
     app: wordpress
 template:
   metadata:
     labels:
       app: wordpress
   spec:
     containers:
       - name: wordpress
         image: wordpress:7.3-apache
         imagePullPolicy: Always
         env:
           - name: DB_USER
             valueFrom:
               secretKeyRef:
                 name: "cloudsql-db-credentials"
                 key: username
           - name: DB_PASSWORD
             valueFrom:
               secretKeyRef:
                 name: "cloudsql-db-credentials"
                 key: password
         ports:
           - containerPort: 80
             name: wordpress
           - containerPort: 443
             name: ssl

이것은 wordpress를 실행하기에 충분하지만 데이터베이스나 지속적인 nfs가 없습니다.클라우드 ql 에이전트를 하나씩 추가합니다.

       - name: cloudsql-proxy
         image: gcr.io/cloudsql-docker/gce-proxy:1.11
         command: ["/cloud_sql_proxy",
                   "-instances=[YOUR INSTANCESTRING THAT WE LOOKED UP]=tcp:3306",
                   "-credential_file=/secrets/cloudsql/credentials.json"]
         securityContext:
           runAsUser: 2  # non-root user
           allowPrivilegeEscalation: false
         volumeMounts:
           - name: cloudsql-instance-credentials
             mountPath: /secrets/cloudsql
             readOnly: true
     volumes:
       - name: cloudsql-instance-credentials
         secret:
           secretName: cloudsql-instance-credentials

멋지다. 현재 우리는localhost를 사용하여 우리의 클라우드 SQL에 접근할 수 있다:) 이것은 기본적으로pod에 두 번째 용기를 추가합니다. 3306에 제출된 모든 내용을 우리의 클라우드 SQL 실례에 에이전트하고 유량을 공공 네트워크에 노출하지 않습니다.
이제 NFS에 wp 컨텐츠 디렉토리를 마운트하려고 합니다.

volumeMounts:
           - name: my-pvc-nfs
             mountPath: "/var/www/html/wp-content"
volumes:
        - name:  my-pvc-nfs
        nfs:
            server: 10.3.240.20
            path: "/"

이제 말하기 시작할 거야. 그런데 마리오, 왜 해커가 IP를 고정한 NFS를이유가 있어요.이것은 내가 알고 있는 유일한 내부 dns가 정상적으로 일을 할 수 없는 상황이다.
지금 우리는 hpa를 창설하여 우리의 기중기를 확장할 수 있다

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
 name: wordpress
 namespace: default
spec:
 maxReplicas: 10
 metrics:
   - resource:
       name: cpu
       targetAverageUtilization: 50
     type: Resource
 minReplicas: 3
 scaleTargetRef:
   apiVersion: extensions/v1beta1
   kind: Deployment
   name: wordpress

우리의 모든 wp 내용 파일은 nfs에 들어가서 실례 간에 공유됩니다.네, 맞습니다. NFS는 현재 우리의 단일 고장이지만 NFS는 한 대의 기계만 운행하는 것보다 훨씬 안정적입니다.만약redis 같은 캐시를 사용하거나 fpm 캐시를 추가하면 캐시 시간을 더욱 단축할 수 있습니다.
멋있지 않아요?
기본적인 Kubernetes/클라우드 로밍에 관심이 있으십니까?알려주세요.