酷!學園

等等，你這裡的host是實體主機？

基本上，經過 NAT 之後， 外面是無法 PING 進來的。
除非你用 routing mode(不同subnet) 或用 bridge(相同subnet)
用 routing 的話, 那需要雙方設定 gateway 互相指向。

好工作！不做嗎？

1. 如果 chmod 777 可以的話，那幾乎可以排除是 selinux 的影響。
chown_uploads=YES
chown_username=SAS
anon_umask=077
因爲你使用了 chown，上傳後身份就改變了，所以 guest 會無法 ls / dir 那是正常的。
這其實也是匿名上傳的建議做法，沒啥不好，並非遇到問題了。

2. 在匿名上傳的 ftp 管理中，需要本機的管理員檢核過上傳的文件，再決定是否開放匿名 ftp 下載，若覺得可以，執行 chown vsftpd 修改允許之文件即可。

歡迎啊～

非常感謝您的意見！因爲網站好久沒維護了，不足之處還請多多包涵～～

Runing a descheduler on your own K8S cluster

v1.0
2019-08-01


一，前言

當我們建置完成一個多 worker nodes 的 K8S cluster 之後，本身就能提供相當的容錯能力。也就是當其中一臺 worker 節點故障或是用 drain 命令排除的時候，運行其上的 pods 會自動轉移至其他良好的 worker 節點上。然而，當故障節點修復上線或用 uncordon 命令加回 cluster 之後，已經處於運行狀態的 pods 並不會自動轉移回康復節點， 只有新產生的 pods 才會被安排在其上運行。

有時候，不同的 node 或因資源不同或因工作量不同，會導致各自有不同的負載：有些節點很忙、有些則很閒。

爲解決上述情況，除了管理員人爲調配之外，我們也可以藉助一個名爲 DeScheduler 的工具來實現服務的自動化平衡調度。


二，關於 DeScheduler

如下爲 DeScheduler 的 GitHub:
   https://github.com/kubernetes-incubator/descheduler

有興趣的朋友可以先去瞭解它的設檔細節，尤其是其中的 Policy and Strategies：

• RemoveDuplicates
• LowNodeUtilization
• RemovePodsViolatingInterPodAntiAffinity
• RemovePodsViolatingNodeAffinity

這裏暫時不討論這 4 種基本策略的內容了，我們只需要將所要的策略配置爲 ConfigMap 即可(一個單一的 ConfigMap 可以配置多個策略)。


三，部署 DeScheduler

3.1 建立一個空白目錄：
mkdir descheduler-yaml
cd descheduler-yaml
3.2 建置 ClusterRole & ServiceAccount：
cat > cluster_role.yaml << END
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: descheduler
  namespace: kube-system
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "delete"]
- apiGroups: [""]
  resources: ["pods/eviction"]
  verbs: ["create"]
END
kubectl apply -f cluster_role.yaml
kubectl create sa descheduler -n kube-system
kubectl create clusterrolebinding descheduler \
    -n kube-system \
    --clusterrole=descheduler \
    --serviceaccount=kube-system:descheduler
3.3 配置 ConfigMap：
cat > config_map.yaml << END
apiVersion: v1
kind: ConfigMap
metadata:
  name: descheduler
  namespace: kube-system
data:
  policy.yaml: |- 
    apiVersion: descheduler/v1alpha1
    kind: DeschedulerPolicy
    strategies:
      RemoveDuplicates:
         enabled: true
      LowNodeUtilization:
         enabled: true
         params:
           nodeResourceUtilizationThresholds:
             thresholds:
               cpu: 20
               memory: 20
               pods: 20
             targetThresholds:
               cpu: 50
               memory: 50
               pods: 50
      RemovePodsViolatingInterPodAntiAffinity:
        enabled: true
      RemovePodsViolatingNodeAffinity:
        enabled: true
        params:
          nodeAffinityType:
          - requiredDuringSchedulingIgnoredDuringExecution
END
kubectl apply -f config_map.yaml
#注意： 這裏我們將 RemoveDuplicates 策略設定爲啓用(enabled: true)，如果不需要自動將 pods 分配到新成員節點的話，可以設定爲停用(enabled: false)。如果系統資源充足而達不到觸發條件，可以調低 LowNodeUtilization 策略的 thresholds 數值(cpu, momory, pod 數量，這三者要同時滿足才能觸發作動)。

3.4 配置 CronJob：
cat > cron_job.yaml << END
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: descheduler
  namespace: kube-system
spec:
  schedule: "*/30 * * * *"
  jobTemplate:
    metadata:
      name: descheduler
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: "true"
    spec:
      template:
        spec:
          serviceAccountName: descheduler
          containers:
          - name: descheduler
            image: komljen/descheduler:v0.6.0
            volumeMounts:
            - mountPath: /policy-dir
              name: policy-volume
            command:
            - /bin/descheduler
            - --v=4
            - --max-pods-to-evict-per-node=10
            - --policy-config-file=/policy-dir/policy.yaml
          restartPolicy: "OnFailure"
          volumes:
          - name: policy-volume
            configMap:
              name: descheduler
END
kubectl apply -f cron_job.yaml
# 注意：這裏設定的 CronJob 是每 30 分鐘執行一次，假如想在測試時更快驗證效果，可以調整爲更短的時間。


四，驗證

4.1 確認 CronJob:
kubectl get cronjobs -n kube-system確定可以看到類似如下的結果:
NAME          SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
descheduler   */30 * * * *   False     0         2m              32m

4.2 確認完成工作的 pods:
kubectl get pods -n kube-system | grep Completed會看到類似如下的結果：
descheduler-1564670400-67tqx                   0/1     Completed   0          1H
descheduler-1564670700-2vwhv                   0/1     Completed   0          32m
descheduler-1564671000-g69nc                   0/1     Completed   0          2m

4.3 檢查 logs：
kubectl -n kube-system logs descheduler-1564671000-g69nc如果沒觸發任何作動的話，最後一行會類似如下：
...
I0505 11:55:08.160964       1 node_affinity.go:72] Evicted 0 pods

4.4 排擠測試節點：
kubectl drain worker03.localdomain --ignore-daemonsets --delete-local-data  --grace-period=0 --force
kubectl get nodes worker03.localdomain確認節點狀態類似如下：
NAME                   STATUS                     ROLES    AGE   VERSION
worker03.localdomain   Ready,SchedulingDisabled   <none>   71d   v1.15.0

等待片刻，確認所有 running pods 都只運行在其他 workers 上面：
web-6fc4fb46d-k5pzr              1/1     Running   0          88s     10.47.0.23   worker01.localdomain   <none>           <none>
web-6fc4fb46d-l9h4j              1/1     Running   0          52s     10.39.0.24   worker02.localdomain   <none>           <none>
web-6fc4fb46d-mqwqv              1/1     Running   0          85s     10.47.0.26   worker01.localdomain   <none>           <none>
web-6fc4fb46d-phr8r              1/1     Running   0          71s     10.47.0.8    worker01.localdomain   <none>           <none>
web-6fc4fb46d-t5ct7              1/1     Running   0          80s     10.47.0.27   worker01.localdomain   <none>           <none>
web-6fc4fb46d-vq4mk              1/1     Running   0          5m38s   10.39.0.8    worker02.localdomain   <none>           <none>
web-6fc4fb46d-ww2nq              1/1     Running   0          6m8s    10.47.0.10   worker01.localdomain   <none>           <none>
web-6fc4fb46d-wz8vl              1/1     Running   0          58s     10.39.0.22   worker02.localdomain   <none>           <none>
web-6fc4fb46d-xvk48              1/1     Running   0          5m25s   10.39.0.11   worker02.localdomain   <none>           <none>
web-6fc4fb46d-xxr5q              1/1     Running   0          5m56s   10.47.0.16   worker01.localdomain   <none>           <none>
web-6fc4fb46d-zcg6l              1/1     Running   0          2m29s   10.47.0.18   worker01.localdomain   <none>           <none>
web-6fc4fb46d-zh7zv              1/1     Running   0          11m     10.39.0.19   worker02.localdomain   <none>           <none>
web-6fc4fb46d-zldt7              1/1     Running   0          5m31s   10.39.0.4    worker02.localdomain   <none>           <none>
web-6fc4fb46d-zxrxw              1/1     Running   0          31m     10.39.0.7    worker02.localdomain   <none>           <none>

4.4 將節點復原：
kubectl uncordon worker03.localdomain
kubectl get nodes確認所有節點都處於 ready 狀態：
NAME                   STATUS   ROLES    AGE   VERSION
master01.localdomain   Ready    master   71d   v1.15.0
master02.localdomain   Ready    master   71d   v1.15.0
master03.localdomain   Ready    master   71d   v1.15.0
worker01.localdomain   Ready    <none>   71d   v1.15.0
worker02.localdomain   Ready    <none>   71d   v1.15.0
worker03.localdomain   Ready    <none>   71d   v1.15.0

觀察 CronJob 剛有執行最近一次工作：
kubectl get pods -n kube-system | grep Completed看到類似如下的結果：
descheduler-1564671600-spl42                   0/1     Completed   0          1h
descheduler-1564671900-2sn9j                   0/1     Completed   0          30m
descheduler-1564672200-sq5zw                   0/1     Completed   0          77s

再次檢查 logs:
kubectl -n kube-system logs descheduler-1564672200-sq5zw將會發現有相當數量的 pods 被 evicted 了：
...
I0801 15:11:00.012104       1 node_affinity.go:72] Evicted 20 pods

確認 pods 被重新分配回節點：
web-6fc4fb46d-n687t              1/1     Running   0          87s     10.42.0.17   worker03.localdomain   <none>           <none>
web-6fc4fb46d-nzdrs              1/1     Running   0          91s     10.42.0.16   worker03.localdomain   <none>           <none>
web-6fc4fb46d-qrn6n              1/1     Running   0          2m8s    10.47.0.14   worker01.localdomain   <none>           <none>
web-6fc4fb46d-qxd8v              1/1     Running   0          2m1s    10.39.0.15   worker02.localdomain   <none>           <none>
web-6fc4fb46d-rpw8b              1/1     Running   0          70s     10.42.0.11   worker03.localdomain   <none>           <none>
web-6fc4fb46d-rxxrn              1/1     Running   0          2m3s    10.47.0.19   worker01.localdomain   <none>           <none>
web-6fc4fb46d-svts8              1/1     Running   0          2m6s    10.47.0.15   worker01.localdomain   <none>           <none>
web-6fc4fb46d-v9q9c              1/1     Running   0          2m4s    10.47.0.17   worker01.localdomain   <none>           <none>
web-6fc4fb46d-x5vrs              1/1     Running   0          110s    10.39.0.21   worker02.localdomain   <none>           <none>
web-6fc4fb46d-xfrnh              1/1     Running   0          76s     10.42.0.8    worker03.localdomain   <none>           <none>
web-6fc4fb46d-xmz64              1/1     Running   0          7m11s   10.42.0.4    worker03.localdomain   <none>           <none>
web-6fc4fb46d-z2xhw              1/1     Running   0          7m9s    10.42.0.7    worker03.localdomain   <none>           <none>
web-6fc4fb46d-zkv95              1/1     Running   0          7m12s   10.42.0.2    worker03.localdomain   <none>           <none>
web-6fc4fb46d-zltxl              1/1     Running   0          105s    10.47.0.6    worker01.localdomain   <none>           <none>


五，結論

透過 DeScheduler 我們可以實現動態的服務應用自動化配置，將負載平均到所有的 worker 節點，可確保 cluster 資源消費的合理化，有助於提升容錯性與服務穩定性。值得一試。

Using Ceph RBD Storage Classes in K8S

Author: netman<netman@study-area.org>
Date: 2019-07-25


一，前言

K8S 中可以使用的 volume 種類非常多，同時也提供 Storage Class 的方式讓管理員更方便的調用定義好的儲存種類。有興趣的話可以參考官方文件：
   https://kubernetes.io/docs/concepts/storage/volumes/
   https://kubernetes.io/docs/concepts/storage/persistent-volumes
   https://kubernetes.io/docs/concepts/storage/storage-classes/

本篇文章僅以簡單的實作形式來說明如何在 K8S 中使用 Ceph RBD 這一儲存資源。


二，前提條件

在展開實作之前，我們假設如下環境已經建置完成並且正常運作中：
Ceph Storage (monitors: 192.168.100.21-23)
K8S Cluster (用 kubeadm 部署)
這裏不再討論如何建置上述系統了，請另行參考其他文章。


三，實作步驟

3.1 於 ceph 上面建立專用的 pool 並設定帳號權限：
ceph osd pool create kube 32 32    # 具體的 PG number 請根據現況調整
ceph osd pool application enable 'kube' 'rbd'
ceph auth get-or-create client.kube mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=kube'
3.2 記錄如下 base64 編碼值( K8S 設定 secrets 需要一致)：
ceph auth get-key client.admin | base64    # 輸出將對應到 k8s 的 ceph-secret-admin secret
ceph auth get-key client.kube | base64     # 輸出將對應到 k8s 的 ceph-secret-kube secret
3.3 在 k8s cluster 中的 worker nodes 上面安裝 ceph-common, 並將 ceph monitor 中的 admin key 檔案複製過來：
yum install -y ceph-common
scp 192.168.100.21:/etc/ceph/ceph.client.admin.keyring /etc/ceph/
3.4 在 k8s 的操作主機(已經設定好context並能順利執行kubectl, 同時也能執行git命令)建立一個專用工作目錄：
mkdir ~/kube-ceph
cd ~/kube-ceph
3.5 建立 secrets yaml:
cat > kube-ceph-secret.yaml << END
apiVersion: v1
kind: Secret
metadata:
  name: ceph-secret-admin
type: "kubernetes.io/rbd"
data:
  key: QVFEYzF0SmNMaVpkRmhBQWlKbUhNbndaR2tCdldFcThXWDhaaXc9PQ==
---
apiVersion: v1
kind: Secret
metadata:
  name: ceph-secret-kube
type: "kubernetes.io/rbd"
data:
  key: QVFDSFdUaGROcC9LT2hBQUpkVG5XVUpQUOYrZGtvZ2k3S0Zwc0E9PQ==
END
3.6 建立 Storage Class yaml:
cat > kube-ceph-sc.yaml << END
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: ceph-rbd
#provisionen: kubernetes.io/rbd
provisioner: ceph.com/rbd
parameters:
  monitors: 192.168.100.21:6789,192.168.100.22:6789,192.168.100.23:6789
  adminId: admin
  adminSecretName: ceph-secret-admin
  adminSecretNamespace: default
  pool: kube
  userId: kube
  userSecretName: ceph-secret-kube
  userSecretNamespace: default
  imageFormat: "2"
  imageFeatures: layering
END
3.7 建立 Persistent Volume Claim (PVC) yaml:
cat > kube-ceph-pvc.yaml << END
metadata:
  name: ceph-k8s-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ceph-rbd
  resources:
    requests:
      storage: 1Gi
END
3.8 因爲透過 kubeadm 部署 k8s 的原因，其內建的 provider 並沒有提供 rbd 的支援(provisioner: kubernetes.io/rbd)，會遇到如下 error:
persistentvolume-controller     Warning   ProvisioningFailed  Failed to provision volume with StorageClass "ceph-rbd": failed to create rbd image: executable file not found in $PATH, command output:

我們需要另行下載並部署延伸支援(provisioner: ceph.com/rbd, 上面的 Storage Class yaml 已經修改爲延伸支援了)：
git clone  https://github.com/kubernetes-incubator/external-storage
cd external-storage/ceph/rbd/deploy/rbac/
kubectl apply -f ./
3.9 確認 rbd-provisioner pod 有正常運作：
kubectl get pods# 確定可以看到類似如下的 pod 在 Running 的狀態：
rbd-provisioner-9b8ffbcc-bwzvr   1/1     Running   0          58s

3.10 套用 ceph rbd 並將 ceph-rbd Storage Class 設定爲 default：
cd ~/kube-ceph
kubectl apply -f ./
kubectl patch storageclass ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
3.11 驗收成果
kubectl get StorageClass# 確認 ceph-rbd 是唯一的 default
NAME                 PROVISIONER    AGE
ceph-rbd (default)   ceph.com/rbd   31s

kubectl get pvc# 確認 pvc 有正確的 bound 起來
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
ceph-k8s-claim   Bound    pvc-00840751-aedf-11e9-8a7d-525400b83b04   1Gi        RWO            ceph-rbd       75s

同時，在 ceph 那邊也能看到新的 rbd image 被自動建立起來：
rbd list -p kube# 可以看到類似如下的結果：
kubernetes-dynamic-pvc-755378b8-aedf-11e9-984f-16b92f357547

3.12 將 pvc 實作於 pod 內：
cat > kube-ceph-pod.yaml << END
apiVersion: v1
kind: Pod
metadata:
  name: kube-ceph-pod       
spec:
  containers:
  - name: ceph-busybox
    image: busybox         
    command: ["sleep", "60000"]
    volumeMounts:
    - name: ceph-volume       
      mountPath: /usr/share/ceph-rbd
      readOnly: false
  volumes:
  - name: ceph-volume 
    persistentVolumeClaim:
      claimName: ceph-k8s-claim
END

named[7962]: zone XXX.edu/IN: loaded serial 158
上面這行就看得到 serial 是 158
或是，簡單些，你修改 master 上面的 record，然後將 dns server 指定 slave 看看是否能看到？

logout 再 login 一次呢？

節省哥好！ 歡迎光臨^_^

我猜應該是保留給 private network 的就不能 delegate 了...
雖然我沒再去測試了，我猜 16 之於 172.in-addr.arpa 應該也是如此。

忍不住動手裝了一個 bind 來測試...

看起來似乎不允許超過一個小數點的 PTR record?
我再試試其他方法...

不對啊，你上次的 log 就是 168.192.in-addr.arpa 這個 zone 了呢...

你修改回昨天的，但將 twcc.wan.192 移到別處（讓bind抓不到）
重新啓動後用 dig 查一下  NS 跟 SOA ？

與 class 無關，如果你的反解 zone 是 172.in-addr.arpa.
那你第一筆的 record 要這樣設：
161.79.17 IN PTR your.forward.dns.name.
(請注意有沒有結尾的小數點)

先看看 log :

grep named /var/log/messages