大約在一年多之前，因為公司的開發環境都是Macbook，所以一些好用的開發工具資源都很好找，但在Windows平台上，沒有什麼好用的工具，最近因為一些需求導致要協助幫忙尋找，然後就有了這篇文章

在以往使用Macbook的時候，都會使用telepresence作為本地與kubernetes cluster的串接工具，而在windows上目前我只找到bridge to kubernetes這個附屬在visual studio與visual studio code下的套件，加上vs code在macbook也可以使用，所以這篇文章就以Macbook為基礎驗證，當然windows也是可行的

以下預設已經設定完kubernetes cluster的連線，並且vs code已經可以連上kubernetes cluster

首先打開vs code，安裝bridge to kubernetes，之後按下command +⇧+P，開始設定

接著會直接讀取連線的namespace的設定，直接讀出namespace中的service，這裡只有設定了一個service，選擇他

接著輸入你要串接此service到本地的port號，我本地會使用docker啟動一個nginx，設定8080

然後選取config設定，這裡因為我不是藉由執行程式啟動，所以我選擇 with out lauch configuration，要注意的是，選擇此設定要連接至cluster需要手動執行task

然後是選擇需要全部導流(for 開發)還是隔離導流(for 正式)，這裡選擇全部導流

這時右下角會顯示已經設定完成，此時專案內也會出現一個.vscode的資料夾，其中有一份tasks.json，內容就是我們剛剛設定的相關參數

接著我們先打開kubernetes上的service ip看看

接著本地執行docker 設定首頁，後面我修改成456

然後回到vs code 選擇tasks.json 然後到上方的terminal 下拉選擇run tasks

接著就會開始執行橋接導流工作，工作原理是會將原本的nginx containers替換掉，將流量導流到本地，並且同namespace內的其他service也會被接至本地虛擬ip上，讓本地的服務也可以連接上其他的service

然後我們再回去打開剛剛kubernetes上的service ip

然後去檢查本地的docker log

到目前已經確認將kubernetes上的nginx導流至本地了，但官方文件說明這個只適用於單一Pod的服務，所以以方便性來看，只能算克難的使用，只能等看看telepresence 2.0是否能如期推出windows的版本了

然後如果要中斷導流，在vs code下方有個cluster的連接符號，像是天線的那個，點開他

選擇Disconnect current session 即可中斷導流，讓kubernetes的導流恢復正常

最後分析一下優缺點，優點是windows可以使用，linux與mac有更好用的telepresence，缺點的話，只適用於單一pod的服務，並且如果有跨namespace的其他服務，是無法被連接到的，telepresence反而比較可以適用整套cluster的導流，如果非windows不可的話，才建議使用bridge to kubernetes，因為沒得選…

參考資料

• https://docs.microsoft.com/zh-tw/visualstudio/containers/overview-bridge-to-kubernetes?view=vs-2019
• https://code.visualstudio.com/docs/containers/bridge-to-kubernetes

GKE 啟用CSI之後，可以針對相關的Class型態進行Snapshot設定，直接對PVC進行備份，並在日後可以直接還原使用

首先先設置csi使用的class，使用預設也可，但預設需要掛載在pod上才會創建對應的磁區，這裡為了展示所以使用自定義的class

vi csi-class.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-pd
provisioner: pd.csi.storage.gke.io
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  type: pd-balanced

kubectla apply -f csi-class.yaml

接著建立PVC

vi ftp-volume.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ftp-volume
  namespace: ftp
spec:
  storageClassName: csi-pd
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

kubectl apply -f ftp-volume.yaml

接著開始設定snapshot class

vi snapshot-class.yaml

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshotClass
metadata:
  name: snapshot-class
driver: pd.csi.storage.gke.io
deletionPolicy: Delete

kubectl apply -f snapshot-class.yaml

然後就可以開始進行備份的設定

vi ftp-snapshot.yaml

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
  name: ftp-snapshot
  namespace: ftp
spec:
  volumeSnapshotClassName: snapshot-class
  source:
    persistentVolumeClaimName: ftp-volume

kubectl apply -f ftp-snapshot.yaml

這時就會開始進行snapshot，接著可以查詢是否已經備份

kubectl get volumesnapshotcontents -n ftp

NAME                                               AGE
snapcontent-02628a1a-a89c-4255-9a40-0fccbfc4bc5d   6s

接著可以確認是snapshot是否可以使用

kubectl get volumesnapshot -n ftp \
        -o custom-columns='NAME:.metadata.name,READY:.status.readyToUse'

當顯示 READY為True時，代表此snapshot已經完成，並可以使用

NAME           READY
ftp-snapshot   true

接著將snapshot設置還原為PVC

vi back-to-pvc.yam

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ftp-bcakup
  namespace: ftp
spec:
  dataSource:
    name: ftp-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

kubectl apply -f back-to-pvc.yaml

然後查詢PVC

kubectl get pvc -n ftp

看到出現PVC就代表還原完成，可以掛載給pod使用了

NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
ftp-bcakup   Bound    pvc-78dca4d4-905f-4111-a2f2-283aa33d829e   100Gi      RWO            standard       36s
ftp-volume   Bound    pvc-bbd19786-7b92-4b35-877f-e48aedb92ba8   100Gi      RWO            csi-pd         16m

• 參考資料
• https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/volume-snapshots#creating_a_volumesnapshot

1.GKE啟用 Compute Engine 永久磁碟 CSI 驅動程式

2.找到DB PVC對應的硬碟，並複製，下圖我將300G的磁碟複製成另一顆sqlserver-copy

3.設定新的PV & PVC 將剛剛複製的硬碟設定至GKE讓Pod可以掛載

apiVersion: v1
kind: PersistentVolume
metadata:
  name: sqlserver-volume-pv
  namespace: sqlserver
spec:
  persistentVolumeReclaimPolicy: Delete
  storageClassName: ""
  capacity:
    storage: 300G
  accessModes:
    - ReadWriteOnce
  claimRef:
    namespace: sqlserver
    name: sqlserver-volume-pvc
  gcePersistentDisk:
    pdName: sqlserver-copy
    fsType: ext4
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sqlserver-volume-pvc
  namespace: sqlserver
spec:
  storageClassName: ""
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 300G

4.啟動新的sqlserver服務，並設定pvc為上一步驟製作的名稱

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sqlserver-sts
  namespace: sqlserver
spec:
  serviceName: sqlserver-svc
  replicas: 1
  selector:
    matchLabels:
      app: ms-sqlserver
  template:
    metadata:
      labels:
        app: ms-sqlserver
    spec:
      terminationGracePeriodSeconds: 10
      securityContext:
        fsGroup: 10001
      containers:
      - name: ms-sqlserver
        image: mcr.microsoft.com/mssql/server:2019-latest
        ports:
        - containerPort: 1433
        resources:
          requests:
            cpu: 2
            memory: 6Gi
        env:
        - name: MSSQL_PID
          value: "Developer"
        - name: ACCEPT_EULA
          value: "Y"
        - name: MSSQL_COLLATION
          value: "Chinese_Taiwan_Stroke_CI_AS"
        - name: MSSQL_AGENT_ENABLED
          value: "true"
        - name: SA_PASSWORD
          valueFrom:
            secretKeyRef:
              name: sqlserver-secret
              key: SA_PASSWORD
        volumeMounts:
        - name: sqlserver-volume
          mountPath: /var/opt/mssql
      volumes:
      - name: sqlserver-volume
        persistentVolumeClaim:
          claimName: sqlserver-volume-pvc

5.檢查相關設定是否正常，以及檢查兩台DB內容是否相同

參考資料

1. https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/gce-pd-csi-driver
2. https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/preexisting-pd

這個架構其實是當初在AWS上實做出來的

我早期的部落格文章有提到，這邊就不多描述了

主要是現在GCP新增加了一個Cloud NAT的功能

可以讓理想中，不需要有對外IP的Server可以連接網際網路進行必要更新或版更

大致流程如下

如果沒有VPN tunnel 由辦公室建立內部網路連線

則多建立一台jumper server

建立兩台web server

由jumper server 走內部IP ssh 至兩台web (ssh go key 我就不多說了)

通了之後，建立一個 Cloud NAT

這時候沒有外部IP的兩台web server即可安裝nginx等套件

接著建立個負載平衡

掛上這兩台web

然後記得開個防火牆 80 port

收工

應用面上來說，只會暴露出負載平衡的IP

其餘全部的server沒有所謂的外部IP，沒有IP就沒有資安疑慮，完美！

GCP可以玩的花樣又更進一步了！

剛好有朋友問了這個問題

所以就寫一篇文章簡單講一下

GCP的防火牆設定與AWS的 Security Group 類似，但又有些不同

首先你先開一個你需要的規則

設定名稱，給一個標記，這裡取名tmp

給要允許的iP，port

如下圖

然後去GCE，編輯你需要給這個規則的機器

貼上剛剛設定的標記

如下圖

這樣子就生效了

不過我還是覺得AWS的比較好用，因為GCP的話 SQL還要另外設定

AWS是全部都可以吃同一組規則，不論內外網，與全部的Service

GCP都要分開設，標記對標記的話，也只吃內網規則，不好用就是了

2018/06  更新

GCP修改了 Cloud SQL的HA機制說明

連結點我

主要就是多了一項

Master 60秒沒有回應時，將會啟動 Failover

總算是有達到基本的要求了，期待可以越來越完善

—————————–以下為原文—————————–

其實這篇算是發牢騷，一個簡單的抱怨

希望GCP能快點修改這種不成熟的HA

以往在AWS RDS上的HA機制是

當Master fail,背後的HA Server 會Switch上去

而GCP SQL 上的HA機制是

當Master fail,另一台HA Server 會跟你講

不會觸發，是的你沒看錯，HA Server不會甩你

然後官方文件跟你說觸發條件是

Failover is triggered when the zone where the master is located experiences an outage. If your master instance is experiencing issues not caused by a zone outage, a failover is not initiated.

不想貼google翻譯的話，小弟幫各位翻譯

如果你的Master在A區，Failover在B區，要A區掰掰了才會觸發

如果是A區你的Master掛了，請自求多福，看著B區那台Failover在笑你…

好吧，這就是問題，目前GCP給的回覆是無解，但會排入更新時程

請有使用SQL的朋友多保重…

另一個MA問題是，如果你的Master設定為 假設週一07:00-08:00 維護

你開了Failover與readonly的時候，你會發現這三台的MA Time

全部被鎖定跟Master相同

翻成白話文的意思，就是MA Time一到，你的DB全部會被重啟

搭配上述的HA機制….你應該保佑你公司的服務不是7*24小時…

或是程式端最好寫好一點…

三經半夜設定MA Time的，自求多福吧

這兩天卡了一個問題

Stackdriver Logging的功能在Basic版本上也是可以使用的

但因為後來發現舊LOG檔案太大

中間停止收集

然後清空，再重新啟動時發現

LOG的收集停止了

這時去確認agent的設定檔

找 pos_file的路徑

vi 這個設定檔，會看到目前取得的資料值

把這一行清空，再將agent重啟

LOG的收集就恢復正常了

本來以為是直接爬LOG連續的爬

沒想到還有存進度的值….



這個問題在AWS上遇過，但是AWS即使使用AMI啟動

也是會替換成IP開頭的hostname

而在GCP上則是會沿用上一次壓成的Image

例如我原本使用 web-01的hostname 壓成Image

在使用這個Image啟動後的server還會是web-01

造成做一個就要連線修改一次

這時拿出AWS的經驗，先找出如何呼叫instance的metadata

再使用腳本替換掉，寫了一隻shell
#!/bin/bash

name=`curl “http://metadata.google.internal/computeMetadata/v1/instance/name” -H “Metadata-Flavor: Google”`

hostnamectl set-hostname $name

systemctl restart rsyslog.service

再啟動instance時，在開機啟動碼中填入即可

如果有其他的指令需要開機啟動，可以寫成一隻boot.sh

在壓成image時放入，然後再啟動instance時

一樣使用開機啟動碼去執行

例如，開機替換hostname並拉取web 的設定檔等指令

我寫完shell之後搭配變數使用，可以下 web 就拉取web設定檔

設定 ap 就拉取 ap設定檔等

減少手動部署時間