PATHpilotのブログ

ようやくゴールに到着。ゴールインの前に今回のシステム構成のおさらい。

まず、全てのノードはVM上に作成した。

ホストH/W　Lenovo Minitowr 530 i9 9900 (8core/16thread)　3.10GHz, memory=32GB 
ホストOS　Windows10 Home Edition
親VM　VMWare Workstation Player 15
  dns 1CPU, 1GB (local DNS)
  nfs 1CPU, 1GB (scale pvcマウントに先立つnfs pvcのマウントテスト用）
  子VM　ESXi 6.0
    Kubernetes Nodes (Kubernetes環境構築ESXi)
      master 2CPU, 4GB
      worker1 2CPU, 4GB
      worker2 2CPU, 4GB
    Scale Nodes (scale環境構築ESXi)
      server node 1 (snode1) 1CPU, 2GB
      server node 2 (snode2) 1CPU, 2GB
      gui node (sgui) 1CPU, 3GB

合計システムリソース　CPU 11、memory 21GB

今回のホストH/Wではこれがほぼほぼ上限の構成となる。当初Kubernetesは2GBメモリーで構成したけれども、メモリーが足りないようで頻繁にハングしたので4GBに増強。Scale GUIノードも2GBでハングしので3GBに増強。この結果、今時点においてScale CSIドライバー試験が出来てはいる。

それではゴールインストーリの始まり始まり、、、、

CSI Driverのインストール

KubernetesのインストールとScaleのインストールはそれぞれのブログを参照して下さい。Local DNSとDNS利用留意点についても同様です。

Scale GUIサーバー上での作業

ユーザーグループ　csiadminの作成

cd /usr/lpp/mmfs/gui/cli

[root@localhost cli]# ./mkusergrp CsiAdmin --role csiadmin
[root@localhost cli]# ./lsusergrp
Name ID Role
Administrator 1 admin
SecurityAdmin 2 securityadmin
StorageAdmin 3 storageadmin
SystemAdmin 4 systemadmin
Monitor 5 monitor
SnapAdmin 6 snapadmin
DataAccess 7 dataaccess
ProtocolAdmin 8 protocoladmin
UserAdmin 9 useradmin
CsiAdmin 10 csiadmin
CnssOperator 11 cnssoperator
EFSSG1000I The command completed successfully.

CSIドライバーからGUIサーバーにログインするユーザーの作成

[root@localhost cli]# ./mkuser csiadmin -p password -g CsiAdmin
EFSSG0019I The user csiadmin has been successfully created.
EFSSG1000I The command completed successfully.
[root@localhost cli]# ./lsuser
Name Long name Password status Group names Failed login attempts Target Feedback Date
admin active SecurityAdmin 0 24.09.2020 09:03:23.000
csiadmin active CsiAdmin 0
EFSSG1000I The command completed successfully.
[root@localhost cli]#

作成したユーザーアカウントでのGUIサーバーへのアクセスを確認.

[root@localhost cli]# curl --insecure -u 'csiadmin:password' -X GET https://sgui.pathpilot.local:443/scalemgmt/v2/cluster
{
"cluster" : {
"clusterSummary" : {
"clusterId" : 1593904468708199996,
"clusterName" : "gpfscluster1.pathpilot.local",
"primaryServer" : "snode-1.pathpilot.local",
"rcpPath" : "/usr/bin/scp",
"rcpSudoWrapper" : false,
"repositoryType" : "CCR",
"rshPath" : "/usr/bin/ssh",
"rshSudoWrapper" : false,
"uidDomain" : "gpfscluster1.pathpilot.local"
},
"capacityLicensing" : {
"liableCapacity" : 10737418240,
"liableNsdCount" : 2,
"liableNsds" : [ {
"nsdName" : "NSD_101",
"liableCapacity" : 5368709120
}, {
"nsdName" : "NSD_102",
"liableCapacity" : 5368709120
} ]
}
},
"status" : {
"code" : 200,
"message" : "The request finished successfully."
}
[root@localhost cli]#

Quotaの設定

[root@localhost cli]# mmlsfs gpfsfs01 --perfileset-quota
flag value description
------------------- ------------------------ -----------------------------------
--perfileset-quota いいえ Per-fileset quota enforcement
[root@localhost cli]# mmlsfs gpfsfs01 -Q
flag value description
------------------- ------------------------ -----------------------------------
-Q none Quotas accounting enabled
none Quotas enforced
none Default quotas enabled
[root@localhost cli]# mmchfs gpfsfs01 -Q yes
mmchfs: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
[root@localhost cli]# mmlsfs gpfsfs01 -Q
flag value description
------------------- ------------------------ -----------------------------------
-Q user;group;fileset Quotas accounting enabled
user;group;fileset Quotas enforced
none Default quotas enabled
[root@localhost cli]#

クラスタに属性情報追加

[root@localhost cli]# mmchconfig enforceFilesetQuotaOnRoot=yes -i
mmchconfig: Command successfully completed
mmchconfig: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
[root@localhost cli]# mmchconfig controlSetxattrImmutableSELinux=yes -i
mmchconfig: Command successfully completed
mmchconfig: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
[root@localhost cli]# mmlsconfig
Configuration data for cluster gpfscluster1.pathpilot.local:
------------------------------------------------------------
clusterName gpfscluster1.pathpilot.local
clusterId 1593904468708199996
autoload no
dmapiFileHandleSize 32
minReleaseLevel 5.0.5.1
ccrEnabled yes
cipherList AUTHONLY
enforceFilesetQuotaOnRoot yes
controlSetxattrImmutableSELinux yes
adminMode central

File systems in cluster gpfscluster1.pathpilot.local:
-----------------------------------------------------
/dev/gpfsfs01

ファイルシステム情報にdf表示追加

[root@localhost cli]# mmchfs gpfsfs01 --filesetdf
[root@localhost cli]#

以降の作業はKubernetesのマスターノードで実行する

CSI OperatorのProvisioning対象ノードであることを示すためラベル付け

[root@master yaml]# kubectl label node worker1.pathpilot.local scale=true --overwrite=true
node/worker1.pathpilot.local labeled
[root@master yaml]# kubectl label node worker2.pathpilot.local scale=true --overwrite=true
node/worker2.pathpilot.local labeled
[root@master yaml]#
[root@master yaml]# kubectl describe node worker1.pathpilot.local
Name: worker1.pathpilot.local
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=worker1.pathpilot.local
kubernetes.io/os=linux
scale=true
....

ネームスペースの作成

[root@master yaml]# kubectl create namespace ibm-spectrum-scale-csi-driver
namespace/ibm-spectrum-scale-csi-driver created

Operatorの作成

[root@master yaml]# kubectl create -f https://raw.githubusercontent.com/IBM/ibm-spectrum-scale-csi/v2.0.0/generated/installer/ibm-spectrum-scale-csi-operator.yaml
deployment.apps/ibm-spectrum-scale-csi-operator created
clusterrole.rbac.authorization.k8s.io/ibm-spectrum-scale-csi-operator created
clusterrolebinding.rbac.authorization.k8s.io/ibm-spectrum-scale-csi-operator created
serviceaccount/ibm-spectrum-scale-csi-operator created
customresourcedefinition.apiextensions.k8s.io/csiscaleoperators.csi.ibm.com created

[root@master yaml]# kubectl get pod,deployment -n ibm-spectrum-scale-csi-driver
NAME READY STATUS RESTARTS AGE
pod/ibm-spectrum-scale-csi-operator-66c7bfc95c-cgvnn 1/1 Running 1 65s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ibm-spectrum-scale-csi-operator 1/1 1 1 65s
[root@master yaml]#
[root@master yaml]# curl -O https://raw.githubusercontent.com/IBM/ibm-spectrum-scale-csi/v2.0.0/operator/deploy/crds/csiscaleoperators.csi.ibm.com_cr.yaml
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5001 100 5001 0 0 9307 0 --:--:-- --:--:-- --:--:-- 9330

csiscaleoperators.csi.ibm.com_cr.yamlの編集

ClusterIDはmmlsclusterが返すcluster idをコピーする。
[root@localhost ~]# mmlscluster

GPFS cluster information
========================
GPFS cluster name: gpfscluster1.pathpilot.local
GPFS cluster id: 1593904468708199996
GPFS UID domain: gpfscluster1.pathpilot.local
Remote shell command: /usr/bin/ssh
Remote file copy command: /usr/bin/scp
Repository type: CCR

Node Daemon node name IP address Admin node name Designation
------------------------------------------------------------------------------------
1 snode-1.pathpilot.local 192.168.1.121 snode-1.pathpilot.local quorum-manager
2 snode-2.pathpilot.local 192.168.1.122 snode-2.pathpilot.local quorum-manager
6 sgui.pathpilot.local 192.168.1.123 sgui.pathpilot.local
7 worker2.pathpilot.local 192.168.1.133 worker2.pathpilot.local
8 worker1.pathpilot.local 192.168.1.132 worker1.pathpilot.local

[root@localhost ~]#

scaleHostpathは mmlsfsが返す”Default mount point” をコピーする。
[root@localhost ~]# mmlsfs all

File system attributes for /dev/gpfsfs01:
=========================================
flag value description
------------------- ------------------------ -----------------------------------
....
-o none Additional mount options
-T /gpfs/gpfsfs01 Default mount point
--mount-priority 0 Mount priority
[root@localhost ~]#

secrets.yamlの編集と適用

Scale GUIサーバーにログオンするためのSecret.yamlを編集する。
ユーザー名とパスワードはbase64に変換した値をセットする。

[root@master ~]# echo -n 'csiadmin' | base64
bXktcGFzc3dvcmQ=
[root@master ~]# echo -n 'password' | base64
bXktdXNlcm5hbWU=
[root@master ~]#

編集後のsecret.yamlは以下のようになる。
apiVersion: v1
kind: Secret
metadata:
name: sguisecret << 自分のsecret名
labels:
product: ibm-spectrum-scale-csi
data:
username: bXktdXNlcm5hbWU= <<< base64で設定(この値はダミーです）
password: bXktcGFzc3dvcmQ= <<< base64で設定(この値はダミーです）

[root@master yaml]# kubectl apply -f secrets.yaml -n ibm-spectrum-scale-csi-driver
secret/sguisecret created

csiscaleoperators.csi.ibm.com_cr.yaml の編集

spec:
# The path to the GPFS file system mounted (either remote/local) on the local Spectrum Scale API host machine.
# ==================================================================================
scaleHostpath: "/gpfs/gpfsfs01"　　<< ここを編集

# A passthrough option that distributes an imagePullSecrets array to the containers
# generated by the csi scale operator. Please refer to official k8s documentation for
# your environment for more details. https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
# ==================================================================================
# imagePullSecrets:
# - APullSecret
# - AnotherOptional

# Below specifies the details of a SpectrumScale cluster configuration used by the
# plugin. It can have multiple values.
# ==================================================================================
clusters:
- id: "1593904468708199996" << ここを編集 mmlsclusterからコピー
secrets: "sguisecret"　　<< ここを編集　secrets.yamlで設定した名前
secureSslMode: false
primary:
primaryFs: "gpfsfs01"　　<< ここを編集
# primaryFset: "< Fileset in Primary Filesystem >" # Optional - default:spectrum-scale-csi-volume-store
# inodeLimit: "< inode limit for Primary Fileset >" # Optional
# remoteCluster: "< Remote ClusterID >" # Optional - This is only required if primaryFs is remote cluster's filesystem and this ID should have separate entry in Clusters map too.
# cacert: "< Name of CA cert configmap for GUI >" # Optional
restApi:
- guiHost: "sgui.pathpilot.local"　　<< ここを編集
#

Lightweight Volumeの作成先filesetの作成

[root@localhost ~]# mmcrfileset gpfsfs01 pvfileset
Fileset pvfileset created with id 1 root inode 19456.
[root@localhost ~]# mmlsfileset gpfsfs01
Filesets in file system 'gpfsfs01':
Name Status Path
root Linked /gpfs/gpfsfs01
pvfileset Unlinked --
[root@localhost ~]#
[root@localhost gpfsfs01]# ls /gpfs/gpfsfs01
[root@localhost gpfsfs01]#
[root@localhost gpfsfs01]# mmlinkfileset gpfsfs01 pvfileset -J /gpfs/gpfsfs01/pvfileset
Fileset pvfileset linked at /gpfs/gpfsfs01/pvfileset
[root@localhost gpfsfs01]# mmlsfileset gpfsfs01
Filesets in file system 'gpfsfs01':
Name Status Path
root Linked /gpfs/gpfsfs01
pvfileset Linked /gpfs/gpfsfs01/pvfileset
[root@localhost gpfsfs01]#
[root@localhost gpfsfs01]# ls /gpfs/gpfsfs01
pvfileset
[root@localhost gpfsfs01]#

Persistent Volume作成先ディレクトリを作成する
[root@localhost pvfileset]# mkdir lwdir

念の為、モードを777にする。これは要らないかもしれない。

[root@localhost pvfileset]# ls -l
合計 1
drwxr-xr-x. 2 root root 4096 8月 27 15:08 lwdir
[root@localhost pvfileset]# chmod 777 lwdir
[root@localhost pvfileset]# ls -l
合計 1
drwxrwxrwx. 2 root root 4096 8月 27 15:08 lwdir

lightweight-storage-class.yamlの編集と適用

[root@localhost pvfileset]# cat lightweight-storage-class.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ibm-spectrum-scale-csi-lt　<< ここを編集
provisioner: spectrumscale.csi.ibm.com
parameters:
volBackendFs: "gpfsfs01" << ここを編集
volDirBasePath: "pvfileset/lwdir"　　<< ここを編集
reclaimPolicy: Delete

[root@master yaml]# kubectl apply -f lightweight-storage-class.yaml
storageclass.storage.k8s.io/ibm-spectrum-scale-csi-lt created

[root@master yaml]# kubectl get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
ibm-spectrum-scale-csi-lt spectrumscale.csi.ibm.com Delete Immediate false 19s

lightweight-pvc.yamlの編集と適用

[root@master yaml]# cat lightweight-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: scale-lw-fset-pvc << ここを編集　podのyamlが参照
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
storageClassName: ibm-spectrum-scale-csi-lt << ここを編集、lightweight-storage-class.yamlのclass名をコピー

[root@master yaml]# kubectl apply -f lightweight-pvc.yaml
persistentvolumeclaim/scale-lw-fset-pvc created

[root@master yaml]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
nfs-claim1 Bound pv0001 3Gi RWO 12d
scale-lw-fset-pvc Pending ibm-spectrum-scale-csi-lt 15s

[root@master yaml]# kubectl describe pvc scale-lw-fset-pvc
Name: scale-lw-fset-pvc
Namespace: default
StorageClass: ibm-spectrum-scale-csi-lt
Status: Pending
Volume:
Labels: <none>
Annotations: volume.beta.kubernetes.io/storage-provisioner: spectrumscale.csi.ibm.com
Finalizers: [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode: Filesystem
Mounted By: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ExternalProvisioning 14s (x2 over 24s) persistentvolume-controller waiting for a volume to be created, either by external provisioner "spectrumscale.csi.ibm.com" or manually created by system administrator
[root@master yaml]#

Microservice pod (mypod-lw01.yaml)の編集と適用

[root@master yaml]# cat mypod-lw01.yaml

apiVersion: v1
kind: Pod
metadata:
name: csi-scale-dynamicdemo-pod　<< このpodの名前
labels:
app: nginx
spec:
containers:
- name: web-server
image: nginx
volumeMounts:
- name: mypvc
mountPath: /usr/share/nginx/html
ports:
- containerPort: 80
volumes:
- name: mypvc
persistentVolumeClaim:
claimName: scale-lw-fset-pvc 　<< pvcの名前
readOnly: false

[root@master yaml]# kubectl apply -f mypod-lw01.yaml
pod/csi-scale-dynamicdemo-pod created

[root@localhost yaml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
csi-scale-dynamicdemo-pod 1/1 Running 0 79s

無事Runningになっている！！！念の為確認。

[root@localhost yaml]# kubectl describe pod csi-scale-dynamicdemo-pod
Name: csi-scale-dynamicdemo-pod
Namespace: default
Priority: 0
Node: worker2.pathpilot.local/192.168.1.133
Start Time: Sat, 29 Aug 2020 21:26:27 +0900
Labels: app=nginx
Annotations: <none>
Status: Running
IP: 10.244.4.4
IPs:
IP: 10.244.4.4
Containers:
web-server:
Container ID: docker://c3572aa8247d4713f234c7b10da00e5644ebe1a4ab176f0b9d8ade727aee3455
Image: nginx
Image ID: docker-pullable://docker.io/nginx@sha256:b0ad43f7ee5edbc0effbc14645ae7055e21bc1973aee5150745632a24a752661
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Sat, 29 Aug 2020 21:26:48 +0900
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/usr/share/nginx/html from mypvc (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-pzg5l (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
mypvc:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: scale-lw-fset-pvc
ReadOnly: false
default-token-pzg5l:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-pzg5l
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 2m3s default-scheduler Successfully assigned default/csi-scale-dynamicdemo-pod to worker2.pathpilot.local
Normal SuccessfulAttachVolume 2m3s attachdetach-controller AttachVolume.Attach succeeded for volume "pvc-6f729ce5-24f2-4310-aee7-d82f60a73f39"
Normal Pulling 106s kubelet, worker2.pathpilot.local Pulling image "nginx"
Normal Pulled 103s kubelet, worker2.pathpilot.local Successfully pulled image "nginx"
Normal Created 102s kubelet, worker2.pathpilot.local Created container web-server
Normal Started 102s kubelet, worker2.pathpilot.local Started container web-server
[root@localhost yaml]#

web-serverが立ち上がっているとの事なので早速動作確認。

Persistent Volumeに対応するディレクトリがgpfs上で自動で作成されていることを確認。
[root@worker2 ~]# ls /gpfs/gpfsfs01/pvfileset/lwdir
pvc-6f729ce5-24f2-4310-aee7-d82f60a73f39

自前のindex.htmlをそのディレクトリに保存する。
[root@worker2 ~]# ls /gpfs/gpfsfs01/pvfileset/lwdir/pvc-6f729ce5-24f2-4310-aee7-d82f60a73f39
index.html
[root@worker2 ~]# cat /gpfs/gpfsfs01/pvfileset/lwdir/pvc-6f729ce5-24f2-4310-aee7-d82f60a73f39/index.html
Hello World! I Love Scale!!!
[root@worker2 ~]#

ブラウザーで作成したPodのWebサーバー(nginx)にアクセスして、index.htmlが表示されることを確認する。

以上

Spectrum Scale Data Management 5.0.5.2をCentOS7.7にインストールする。

Kubernetesのインストールの後での作業。

まずは前さばき作業から。

FirewallとSELINUXの停止

# systemctl stop firewalld
# systemctl disable firewalld
# vi /etc/selinux/config
以下のように行を修正する。
SELINUX=disabled

# setenforce 0

Local DNSへの自分の登録
Local DNSをアクセスするように自分の設定

vi /etc/NetworkManager/NetworkManager.conf
mainセクションにdns=noneを追加する。

[main]
#plugins=ifcfg-rh,ibft
dns=none <<< これを追加

systemctl restart NetworkManager
# vi /etc/resolv.conf

# Generated by NetworkManager
nameserver 192.168.1.250 <<< Local DNSのアドレスを追加する。
nameserver 192.168.1.1

# nmcli c mod ens160 ipv4.dns ""
# systemctl restart NetworkManager
# nmcli d show によってIP4.DNSが消去されていることを確認する。

自分のサーバー名がResolveされることを確認する。
# nslookup snode-1.pathpilot.local
Server: 192.168.1.250
Address: 192.168.1.250#53

Name: snode-1.pathpilot.local ## verify myself is resolved.
Address: 192.168.1.121

NTP同期確認
# systemctl restart chronyd
# timedatectl
VMをサスペンド/リジュームすると同期が止まるので、リジューム後には毎回restartの必要がある。

パスワード無しSSHの構成
自分のところで鍵を作り、その鍵をScale Clusterに参加する自分を含むすべてのノードにコピーする。
# ssh-keygen -t rsa
# ssh-copy-id root@snode-1.pathpilot.local
# ssh-copy-id root@snode-2.pathpilot.local
# ssh-copy-id root@sgui.pathpilot.local
# ssh-copy-id root@worker1.pathpilot.local
# ssh-copy-id root@worker2.pathpilot.local

自分を含む全てのノードにパスワード無しでSSH出来ることを確認する。
# ssh snode-1.pathpilot.local date

Scaleのインストール

スケールモジュールのインストールとビルド
CentOS 7.7の場合、最新のkernel-develを入れるとmmbuildgplがエラーとなるのでベースのレベルにする必要がある。
その為、以下のrpmをCentOSのリポジトリからダウンロードしてインストールする。
# rpm -ihv kernel-devel-3.10.0-1062.el7.x86_64.rpm
それ以外のモジュールは最新を入れる。
# yum -y install cpp gcc gcc-c++ binutils ksh m4

CentPS8の場合はこの問題は起きない（2020年8月時点）ので以下だけの実行でよい。
# yum -y install kernel-devel cpp gcc gcc-c++ binutils ksh m4

# chmod u+x Spectrum_Scale_Data_Management-5.0.5.2-x86_64-Linux-install
# ./Spectrum_Scale_Data_Management-5.0.5.2-x86_64-Linux-install --silent

# cd /usr/lpp/mmfs/5.0.5.2/gpfs_rpms
# rpm -ivh gpfs.adv* gpfs.base*.rpm gpfs.docs*.rpm gpfs.gpl*.rpm gpfs.gskit*.rpm gpfs.msg*.rpm gpfs.license*.rpm gpfs.compression*.rpm gpfs.crypto*.rpm

# export LINUX_DISTRIBUTION=REDHAT_AS_LINUX
# /usr/lpp/mmfs/bin/mmbuildgpl

以降の作業のためにパス設定を行う。
# export PATH=$PATH:/usr/lpp/mmfs/bin
恒久的に設定するために、自分のホームディレクトリ内の.bash_profileを編集し、PATH=$...を追記する。

Scale構成作業

1. Configure Cluster
mmcrcluster
# mmcrcluster -N snode-1.pathpilot.local:quorum-manager,snode-2.pathpilot.local:quorum-manager,sgui.pathpilot.local,worker1.pathpilot.local,worker2.pathpilot.local --ccr-enable -r /usr/bin/ssh -R /usr/bin/scp -C gpfscluster1

2. Apply License
mmchlicense
# mmchlicense server --accept -N snode-1.pathpilot.local,snode-2.pathpilot.local
# mmchlicense client --accept -N sgui.pathpilot.local,worker1.pathpilot.local,worker2.pathpilot.local

3. Start up cluser
mmstartup
# mmstartup -a

4. Edit Stanza file
NSDを定義するStanzaファイルを編集する

ダウンロード - snode1.nsd

5. Create NSD
mmcrnsd
# mmcrnsd -F /root/work/snode1.nsd

6. Create Filesystem
mmcrfs
# mmcrfs gpfsfs01 -F /root/work/snode1.nsd -B 256K -D posix -k all

7. Mount filesystem
mmmount
# mmmount gpfsfs01 -a
# mmlsmount gpfsfs01 -L

以降、実際のコマンド実行記録
[root@localhost gpfs_rpms]# mmcrcluster -N snode-1.pathpilot.local:quorum-manager,snode-2.pathpilot.local:quorum-manager,sgui.pathpilot.local,worker1.pathpilot.local --ccr-enable -r /usr/bin/ssh -R /usr/bin/scp -C gpfscluster1

[root@localhost gpfs_rpms]# mmchlicense server --accept -N snode-1.pathpilot.local,snode-2.pathpilot.local

[root@localhost gpfs_rpms]# mmchlicense client --accept -N sgui.pathpilot.local,worker1.pathpilot.local

[root@localhost gpfs_rpms]# mmlscluster

GPFS cluster information
========================
GPFS cluster name: gpfscluster1.pathpilot.local
GPFS cluster id: 1593904468708199996
GPFS UID domain: gpfscluster1.pathpilot.local
Remote shell command: /usr/bin/ssh
Remote file copy command: /usr/bin/scp
Repository type: CCR

Node Daemon node name IP address Admin node name Designation
------------------------------------------------------------------------------------
1 snode-1.pathpilot.local 192.168.1.121 snode-1.pathpilot.local quorum-manager
2 snode-2.pathpilot.local 192.168.1.122 snode-2.pathpilot.local quorum-manager
6 sgui.pathpilot.local 192.168.1.123 sgui.pathpilot.local
7 worker2.pathpilot.local 192.168.1.133 worker2.pathpilot.local
8 worker1.pathpilot.local 192.168.1.132 worker1.pathpilot.local

[root@localhost gpfs_rpms]#

[root@localhost gpfs_rpms]# /usr/lpp/mmfs/bin/mmstartup -a
2020年 8月 24日 月曜日 06:17:18 JST: mmstartup: Starting GPFS ...

[root@localhost gpfs_rpms]# mmgetstate -a

Node number Node name GPFS state
-------------------------------------------
1 snode-1 active
2 snode-2 active
6 sgui active
7 worker2 active
8 worker1 active
[root@localhost gpfs_rpms]#

[root@localhost gpfs_rpms]# cd /root
[root@localhost ~]# mmcrnsd -F /root/work/snode.nsd
mmcrnsd: Processing disk sdb
mmcrnsd: Processing disk sdc
mmcrnsd: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.

[root@localhost ~]# mmcrfs gpfsfs01 -F /root/work/snode.nsd -B 256K -D posix -k all

The following disks of gpfsfs01 will be formatted on node snode-1.pathpilot.local:
NSD_101: size 5120 MB
NSD_102: size 5120 MB
Formatting file system ...
Disks up to size 146.21 GB can be added to storage pool system.
Creating Inode File
Creating Allocation Maps
Creating Log Files
Clearing Inode Allocation Map
Clearing Block Allocation Map
Formatting Allocation Map for storage pool system
Completed creation of file system /dev/gpfsfs01.
mmcrfs: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.

[root@localhost ~]# mmlsfs all
[root@localhost gpfs_rpms]# mmlsfs all
File system attributes for /dev/gpfsfs01:
=========================================
flag value description
------------------- ------------------------ -----------------------------------
-f 8192 Minimum fragment (subblock) size in bytes
-i 4096 Inode size in bytes
-I 16384 Indirect block size in bytes
-m 1 Default number of metadata replicas
-M 2 Maximum number of metadata replicas
-r 1 Default number of data replicas
-R 2 Maximum number of data replicas
-j cluster Block allocation type
-D posix File locking semantics in effect
-k all ACL semantics in effect
-n 32 Estimated number of nodes that will mount file system
-B 262144 Block size
-Q user;group;fileset Quotas accounting enabled
user;group;fileset Quotas enforced
none Default quotas enabled
--perfileset-quota いいえ Per-fileset quota enforcement
--filesetdf はい Fileset df enabled?
-V 23.00 (5.0.5.0) File system version
--create-time Mon Aug 24 06:43:15 2020 File system creation time
-z いいえ Is DMAPI enabled?
-L 4194304 Logfile size
-E はい Exact mtime mount option
-S relatime Suppress atime mount option
-K whenpossible Strict replica allocation option
--fastea はい Fast external attributes enabled?
--encryption いいえ Encryption enabled?
--inode-limit 873856 Maximum number of inodes in all inode spaces
--log-replicas 0 Number of log replicas
--is4KAligned はい is4KAligned?
--rapid-repair はい rapidRepair enabled?
--write-cache-threshold 0 HAWC Threshold (max 65536)
--subblocks-per-full-block 32 Number of subblocks per full block
-P system Disk storage pools in file system
--file-audit-log いいえ File Audit Logging enabled?
--maintenance-mode いいえ Maintenance Mode enabled?
-d NSD_101;NSD_102 Disks in file system
-A yes Automatic mount option
-o none Additional mount options
-T /gpfs/gpfsfs01 Default mount point
--mount-priority 0 Mount priority
[root@localhost gpfs_rpms]#

[root@localhost ~]# mmmount gpfsfs01 -a
2020年 8月 24日 月曜日 06:44:14 JST: mmmount: Mounting file systems ...
[root@localhost gpfs_rpms]# mmlsmount gpfsfs01 -L
File system gpfsfs01 is mounted on 5 nodes:
192.168.1.121 snode-1
192.168.1.123 sgui
192.168.1.122 snode-2
192.168.1.132 worker1
192.168.1.133 worker2
[root@localhost ~]#

以上でScaleのインストールと構成が完了した。

Scale GUIサーバーのインストール

Scale GUIサーバーをインストールする。

cd /usr/lpp/mmfs/5.0.5.2/gpfs_rpms
[root@sgui gpfs_rpms]# yum install gpfs.java-5.0.5-2.x86_64.rpm

cd ../zimon_rpms/rhel7
[root@localhost rhel7]# yum install gpfs.gss.pmcollector-5.0.5-2.el7.x86_64.rpm
[root@localhost rhel7]# yum install gpfs.gss.pmsensors-5.0.5-2.el7.x86_64.rpm

Install the following on GUI node.
[root@sgui gpfs_rpms]# yum install gpfs.gui-5.0.5-2.noarch.rpm
[root@sgui gpfs_rpms]# systemctl start gpfsgui

GUIにログインするためのユーザーをCLI作成する。
[root@sgui gpfs_rpms]# /usr/lpp/mmfs/gui/cli/mkuser admin -g SecurityAdmin
EFSSG1007A Enter password for User :
EFSSG0225I Repeat the password:
EFSSG0019I The user admin has been successfully created.
EFSSG1000I The command completed successfully.
[root@sgui gpfs_rpms]#

ユーザーを作成した直後のログオン画面。通常画面とはちょっと異なる。

一回上記画面でログインするとそれ以降のログインは普段見慣れた画面になる。

以上

Masterノードの作り方を間違えていた。

kubeadm init時に--pod-network-cidr を指定していなかった。あとkube-flannel.ymlのnet-conf.jsonのNetwork IP設定を間違えていた。

kubeadm resetを実行したけれどもエラーが出てしまってどこまできれいになったか怪しい。後から変なところでハマると悲しいので、masterノードを再インストールした。で、実際に実行した手順。

1. masterノード上で、workerノードを全部deleteした。
2. masterノードの再インストール
3. kubeadm initの実行
4. workerノードでkubeadm resetの実行。workerノードはmasterノードでDeleteすればMasterとの関係を忘れてくれるかと思ったらそうではなかった。でresetが必要となった。
5. workerノードでjoinの実行

以上で、スタートにもどった感じ。
では、なかった。

教訓：Resetの後にflannel.1とcni0をDeteleせよ！

このあと以下のエラーの連打に遭遇した。

[root@localhost yaml]# kubectl describe pod csi-scale-staticdemo-pod

・・・省略・・・

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 47m default-scheduler Successfully assigned ibm-spectrum-scale-csi-driver/ibm-spectrum-scale-csi-operator-55555c45c5-mwv9v to worker2.pathpilot.local
Warning FailedCreatePodSandBox 47m kubelet, worker2.pathpilot.local Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "91c235921db5fe2273132e115cb4c071bbdccb1980815c4a4049c7009c01a13e" network for pod "ibm-spectrum-scale-csi-operator-55555c45c5-mwv9v": networkPlugin cni failed to set up pod "ibm-spectrum-scale-csi-operator-55555c45c5-mwv9v_ibm-spectrum-scale-csi-driver" network: failed to set bridge addr: "cni0" already has an IP address different from 10.244.1.1/24

どうやらcni0がすでに構成されているよ！と言っているようだ。確かにflannel.1とcni0が既に存在している、というかReset前のが残ったままになっている。

[root@localhost work]# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:0c:29:c2:be:18 brd ff:ff:ff:ff:ff:ff
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:bf:38:1d brd ff:ff:ff:ff:ff:ff
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:bf:38:1d brd ff:ff:ff:ff:ff:ff
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:e8:9b:ec:01 brd ff:ff:ff:ff:ff:ff
6: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 6e:fd:57:be:69:71 brd ff:ff:ff:ff:ff:ff
7: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether b2:ab:34:6e:29:22 brd ff:ff:ff:ff:ff:ff
8: veth159ba468@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default
link/ether 5e:c4:42:45:ec:34 brd ff:ff:ff:ff:ff:ff link-netnsid 0

で、以下を実行。

[root@localhost work]# ip link delete flannel.1
[root@localhost work]# ip link delete cni0
[root@localhost work]# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:0c:29:c2:be:18 brd ff:ff:ff:ff:ff:ff
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:bf:38:1d brd ff:ff:ff:ff:ff:ff
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:bf:38:1d brd ff:ff:ff:ff:ff:ff
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:e8:9b:ec:01 brd ff:ff:ff:ff:ff:ff

これで過去をわすれさせて、
[root@localhost yaml]# kubectl describe pod csi-scale-staticdemo-pod はエラー連打がなくなった。

以上

毎回忘れるので備忘録。

export PATH=$PATH:/usr/lpp/mmfs/bin

恒久的に変更するには以下に上記を追記する。

[home directory]/.bash_profile

mmbuildgplがエラーで終了した。Killされている。
詳しい人に聞いたらOut Of Memoryとのこと。
早速VMのメモリを倍増したらmmbuildgplは無事終了。なかなか奥が深いぞ。。。。。make[2]: Entering directory `/usr/src/kernels/3.10.0-1062.el7.x86_64'
  LD      /usr/lpp/mmfs/src/gpl-linux/built-in.o
  CC [M]  /usr/lpp/mmfs/src/gpl-linux/tracelin.o
  CC [M]  /usr/lpp/mmfs/src/gpl-linux/tracedev-ksyms.o
  CC [M]  /usr/lpp/mmfs/src/gpl-linux/ktrccalls.o
  CC [M]  /usr/lpp/mmfs/src/gpl-linux/relaytrc.o
  LD [M]  /usr/lpp/mmfs/src/gpl-linux/tracedev.o
  CC [M]  /usr/lpp/mmfs/src/gpl-linux/mmfsmod.o
  LD [M]  /usr/lpp/mmfs/src/gpl-linux/mmfs26.o
  CC [M]  /usr/lpp/mmfs/src/gpl-linux/cfiles_cust.o
/bin/sh: line 1: 15901 Killed                  ./tools/objtool/objtool check “/usr/lpp/mmfs/src/gpl-linux/cfiles_cust.o”
make[3]: *** [/usr/lpp/mmfs/src/gpl-linux/cfiles_cust.o] Error 137
make[2]: *** [_module_/usr/lpp/mmfs/src/gpl-linux] Error 2
make[2]: Leaving directory `/usr/src/kernels/3.10.0-1062.el7.x86_64'
make[1]: *** [modules] Error 1
make[1]: Leaving directory `/usr/lpp/mmfs/src/gpl-linux’
make: *** [Modules] Error 1
--------------------------------------------------------
mmbuildgpl: Building GPL module failed at Mon Aug 24 17:39:57 JST 2020.
--------------------------------------------------------
mmbuildgpl: Command failed. Examine previous error messages to determine cause

CentOSの日本語表示を英語表示に変える。つまりLocaleを変える。

日本語表示では以下になっている。
# localectl
System Locale: LANG=ja_JP.UTF-8
VC Keymap: jp
X11 Layout: jp

以下を実行すると英語表示設定に変更できる。
# localectl set-locale LANG=en_US.UTF-8

けれども再起動しないと以下のとおり。
# date
2020年 8月 24日 月曜日 17:20:05 JST

localectlコマンドによってLocale設定ファイルは変更されている。つまり再起動するとこれを読むわけ。
# cat /etc/locale.conf
LANG=en_US.UTF-8

強制的にこの構成ファイルを読み込ませる。
# source /etc/locale.conf

すると再起動しなくても変更された。
# date
Mon Aug 24 17:20:42 JST 2020

日本語に戻すには以下の設定を日本語設定に戻せばよい。
# localectl
System Locale: LANG=en_US.UTF-8
VC Keymap: jp
X11 Layout: jp
[root@worker1 gpfs_rpms]#

カーネルのバージョン問題がCentOS7.7へのSpectrum Scaleのインストールを阻んでいるようだ。

Spectrum Scaleの導入に先立って以下を実行する必要がある。Kernelのheader.hを参照する必要があるたけだけれど、これが問題を引き起こしているようだ。

# yum install kernel-devel

これを実行することで以下のディレクトリが作られる。
# ls /usr/src/kernels
3.10.0-1127.18.2.el7.x86_64

しかしunameコマンドは違った値を返す。
# uname -r
3.10.0-1062.el7.x86_64

mmbuildgplはunameが返す値と同じ値を期待してBuildを進める。

以下mmbuildgplの出力結果
mmbuildgpl: Building GPL (5.0.4.2) module begins at 2020年 8月 23日 日曜日 11:01:45 JST.
--------------------------------------------------------
Verifying Kernel Header...
kernel version = 31000999 (310001062000000, 3.10.0-1062.el7.x86_64, 3.10.0-1062)
module include dir = /lib/modules/3.10.0-1062.el7.x86_64/build/include
module build dir = /lib/modules/3.10.0-1062.el7.x86_64/build
kernel source dir = /usr/src/linux-3.10.0-1062.el7.x86_64/include
Cannot find a valid kernel header file. One of these files should exist.
　/lib/modules/3.10.0-1062.el7.x86_64/build/include/linux/version.h
　/usr/src/linux-3.10.0-1062.el7.x86_64/include/linux/version.h
　/usr/src/kernels/3.10.0-1062.el7.x86_64/include/generated/uapi/linux/version.h
　/lib/modules/3.10.0-1062.el7.x86_64/build/include/generated/uapi/linux/version.h

期待するディレクトリが無いのでエラーとなる。
とりあえずの対応策として、マニュアルで以下を実行してみる。

# mkdir 3.10.0-1062.el7.x86_64
# cp -r 3.10.0-1127.18.2.el7.x86_64/* 3.10.0-1062.el7.x86_64

# /usr/lpp/mmfs/bin/mmbuildgpl
事前チェックはパスしえmake Worldに進むが、、、、

以下出力結果make[2]: ディレクトリ `/usr/src/kernels/3.10.0-1062.el7.x86_64' に入ります
LD /usr/lpp/mmfs/src/gpl-linux/built-in.o
CC [M] /usr/lpp/mmfs/src/gpl-linux/tracelin.o
CC [M] /usr/lpp/mmfs/src/gpl-linux/tracedev-ksyms.o
CC [M] /usr/lpp/mmfs/src/gpl-linux/ktrccalls.o
CC [M] /usr/lpp/mmfs/src/gpl-linux/relaytrc.o
LD [M] /usr/lpp/mmfs/src/gpl-linux/tracedev.o
CC [M] /usr/lpp/mmfs/src/gpl-linux/mmfsmod.o
LD [M] /usr/lpp/mmfs/src/gpl-linux/mmfs26.o
CC [M] /usr/lpp/mmfs/src/gpl-linux/cfiles_cust.o
In file included from /usr/lpp/mmfs/src/gpl-linux/cfiles.c:61:0,
from /usr/lpp/mmfs/src/gpl-linux/cfiles_cust.c:54:
/usr/lpp/mmfs/src/gpl-linux/kx.c: 関数 ‘reopen_file’ 内:
/usr/lpp/mmfs/src/gpl-linux/kx.c:5743:7: エラー: 関数 ‘file_release_write’ の暗黙的な宣言です [-Werror=implicit-function-declaration]
file_release_write(fP);
^
cc1: some warnings being treated as errors
make[3]: *** [/usr/lpp/mmfs/src/gpl-linux/cfiles_cust.o] エラー 1
make[2]: *** [_module_/usr/lpp/mmfs/src/gpl-linux] エラー 2
make[2]: ディレクトリ `/usr/src/kernels/3.10.0-1062.el7.x86_64' から出ます
make[1]: *** [modules] エラー 1
make[1]: ディレクトリ `/usr/lpp/mmfs/src/gpl-linux' から出ます
make: *** [Modules] エラー 1
--------------------------------------------------------
mmbuildgpl: Building GPL module failed at 2020年 8月 23日 日曜日 11:06:55 JST.

どうやら、インストールした大元のCentOS7.7と後からインストールしたkernel-develのレベルが異なるとCentOS自体がおかしくなる（uname -rが更新したレベルを認識できない）ようだ。

考えられる対策は2つ、いずれもmmbuildgplが正常終了することが確認できた。

• 1062レベルのkernel-develをインストールする（1062のkernel-devel rpmをダウンロードしてきてインストールする）
• CentOS7.8をインストールする。

今から古いカーネルレベルにするっていうのも考え物だけれど、Spectrum Scale CSIがRHEL 7.5, 7.6, 7.7までしかサポートしていないので、7.7（1062）で行くってことかなぁ、、、、、

毎回「あれ？どうだったっけ？」と悩む（というかメニューがどこにあるのか分からなくなる）ので備忘録。
ESXiのデータストアへのファイルアップロード（ISOイメージ）方法。

ESXiの構成タブでデータストアを表示・選択し右クリックでデータストアの参照を選択。

データストアブラウザが表示されるのでファイルのアップロードを選択。

以降、アップロードしたいファイルを選んでアップロード。

以上。

VM間の共有ハードディスクを作成する。これはSpectrum Scale NSD Serverの共有ハードディスクとして使うため。
ここではsnode-1とsnode-2の2ノード（2VM）間に共有ディスクを構成している。

まずsnode-1の設定の編集でディスクの追加を行う。その際重要なのはSCSIアドレス。ブートディスク、つまりこのVM専用のディスクはSCSI (0:0)、すなわちSCSIチャンネル0に割り当てられ、そのチャンネル用のSCSIコントローラに紐づけられる。このチャンネルは共有しないので、共有するディスクは別のSCSIチャンネルに割り当てる必要がある。以下の図ではSCSI(1:0)。このチャンネルをVM間共有チャネルとする。

注意：シックプロビジョニング（Egerzeroed）でディスクを作成すること。シンだと後でVM起動エラーになるらしい。

ハードディスクの追加をすると、このSCSIチャンネルに対応するSCSIコントローラが現れる。

ここではハードディスクを2個追加するので、ハードディスク追加作業を繰り返す。2個めのハードディスクのSCSIアドレスは(1:1) とする。

次に他方のVMであるsnode-2の設定の編集を開き、ハードディスクの追加を行う。ここでは上記作業で作成した既存のハードディスクを選択する。先ほど作った2つのディスクが(1:0)がsnode-1_3.vmdk、(1:1)がsnode-1_4.vmdkになっている。

それぞれのvmdkをsnode-1と同じSCSIチャンネルに割り当てる。

SCSIバスの共有は物理に設定しておく。書き忘れたけれどsnode-1でも同様に設定しておくこと。

以上で、両VM間で共有するハードディスクを構成できる。

NFSでPersistent Volumeを作る環境が出来たので早速試行。

[root@master ~]# ls yaml
Minikube oss_27.pdf join kubeadm.txt mypv.yaml nginx-iscsi-pod.yamp storage-class-silver.yaml
canal.yaml kubectl_get_pv_mypv.text mypvc.yaml nginx-pod.yaml
iscsi-claim.yaml kubernetes.repo nfs-claim.yaml pod-httpd.yaml
iscsi-pv.yaml mypod.yaml nfs-pv.yaml rbac.yaml

[root@master ~]# kubectl create -f yaml/nfs-pv.yaml
persistentvolume/pv0001 created

ダウンロード - nfs-pv.yaml

[root@master ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv0001 3Gi RWO Recycle Available 13s

[root@master ~]# kubectl create -f yaml/nfs-claim.yaml
persistentvolumeclaim/nfs-claim1 created

ダウンロード - nfs-claim.yaml

[root@master ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
nfs-claim1 Bound pv0001 3Gi RWO 11s

[root@master ~]# kubectl apply -f yaml/nginx-pod.yaml
pod/nginx-pod created

ダウンロード - nginx-pod.yaml

[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 28h
nginx-pod 0/1 ContainerCreating 0 14s
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 28h
nginx-pod 1/1 Running 0 21s
[root@master ~]#

注意：ダウンロードしたyamlファイルのファイル名中の"-"が抜けている（ここのBlogのFile Managerの問題？？）

この状態でNFSサーバーのExportしてディレクトリーに以下を書き込んだ。
# cat index.html

Hello My World

結果は以下。

ちなみにPodのIPアドレスは以下で取得する。
[root@master ~]# kubectl describe pod nginx-pod
Name: nginx-pod
Namespace: default
Priority: 0
Node: worker1/192.168.1.132
Start Time: Fri, 14 Aug 2020 21:36:32 +0900
Labels: <none>
Annotations: Status: Running
IP: 10.96.0.4
IPs:
IP: 10.96.0.4

以上で、Persistent Volumeをテストする環境が出来上がった。

KubernetesでPersistent Volumeの構成環境を準備する。というのも最終ゴールはSpectrum Scale CSIドライバーのテストにあるので、その前段階としてPVをPodに割り当てることができるベース環境を用意したいので。

で、NFSサーバーを用意した。
ESXiにて1CPU + 1GBの最小構成Centos7.7サーバーで立ち上げた。以下、作業記録。なお、インターネットでNFSに関する沢山の情報から学ばせていただいた。

まずはNFSでExposeするディレクトリの作成。
[root@localhost ~]# mkdir /home/nfs
[root@localhost ~]# ls /home/nfs

exportsファイルの編集。とにかく何でもできるように設定。
[root@localhost ~]# vi /etc/exports
[root@localhost ~]# cat /etc/exports
/home/nfs 192.168.1.0/24(async,rw,no_root_squash)

Domainは自分のDNSサーバーのDomainを設定。
[root@localhost ~]# vi /etc/idmapd.conf
[root@localhost ~]# cat /etc/idmapd.conf
[General]
#Verbosity = 0
# The following should be set to the local NFSv4 domain name
# The default is the host's DNS domain name.
#Domain = local.domain.edu
Domain = pathpilot.local

いざ実行：
[root@localhost ~]#
[root@localhost ~]# systemctl start rpcbind
[root@localhost ~]# systemctl start nfs-server
[root@localhost ~]# systemctl start nfs-lock
[root@localhost ~]# systemctl start nfs-idmapd
[root@localhost ~]# systemctl enable nfs-server
Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-server.service to /usr/lib/systemd/system/nfs-server.service.
[root@localhost ~]# systemctl stop firewalld
[root@localhost ~]# systemctl disable firewalld
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
[root@localhost ~]# ls /home/nfs

クライアント側からのマウントとチェック。
mount nfs1.pathpilot.local:/home/nfs /mnt/nfs

無事マウント出来ることを確認して無事終了。

後からメモ：

これはkubeadm init で--pod-network-cidrを指定していなかったこととkube-flannel.ymlの編集を間違えていたことに起因していたと判明。内部エラーからsubnet.envが出力できなかったのだと思う。

早速はまった。
podをrunさせようにもCreatingContainerから先に進まない。

[root@master ~]# kubectl run nginx --image=nginx:1.11.3
pod/nginx created

[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 0/1 ContainerCreating 0 8s

podの状態を見てみる。
[root@master ~]# kubectl describe pod nginx
Name: nginx
Namespace: default
Priority: 0
Node: worker1/192.168.1.132
Start Time: Thu, 13 Aug 2020 16:45:28 +0900
Labels: run=nginx
Annotations: <none>
Status: Pending
IP:
IPs: <none>
Containers:
nginx:
Container ID:
Image: nginx:1.11.3
Image ID:
Port: <none>
Host Port: <none>
State: Waiting
Reason: ContainerCreating
Ready: False
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-5ptbc (ro)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
default-token-5ptbc:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-5ptbc
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 18s default-scheduler Successfully assigned default/nginx to worker1
Warning FailedCreatePodSandBox 18s kubelet, worker1 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "99d3c9e5f10d685372b5d36a17ee032520bbf0d712fd416cf08ea8e4700fba2d" network for pod "nginx": networkPlugin cni failed to set up pod "nginx_default" network: open /run/flannel/subnet.env: no such file or directory

中略（同じメッセージの繰り返しなので）

Warning FailedCreatePodSandBox 10s kubelet, worker1 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "cda26db8d28e9f46b2abf7c1a65e0222b807d7126470de78cc7b8888e6046a6a" network for pod "nginx": networkPlugin cni failed to set up pod "nginx_default" network: open /run/flannel/subnet.env: no such file or directory
Normal SandboxChanged 6s (x12 over 17s) kubelet, worker1 Pod sandbox changed, it will be killed and re-created.
Warning FailedCreatePodSandBox 6s (x4 over 9s) kubelet, worker1 (combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "2fc4739b4f2e5c105529507eecee1a71730f63abf87f2e66646f9b4b0b568c72" network for pod "nginx": networkPlugin cni failed to set up pod "nginx_default" network: open /run/flannel/subnet.env: no such file or directory

どうも/run/flannel/subnet.envが無いからネットワークが構成できないといっているようだ。インターネットで調べてみると同じ問題に直面した諸先輩はマニュアルで以下ファイルを作って解決しているようだ。ちなみに私はkubeadm initでDefaultのネットワーク設定にしているので以下を10.96.0.0を設定している。

[root@master ~]# cat /run/flannel/subnet.env
FLANNEL_NETWORK=10.96.0.0/12
FLANNEL_SUBNET=10.96.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true
[root@master ~]#

このファイルをMasterに作ったのだが（Masterになかったから）それでは解決しなかった。で、worker1にも同じファイルを作った。それで再実行。

[root@master ~]# kubectl delete pod nginx
pod "nginx" deleted
[root@master ~]# kubectl run nginx --image=nginx:1.11.3
pod/nginx created
[root@master ~]# kubectl describe pod nginx
Name: nginx
Namespace: default
Priority: 0
Node: worker1/192.168.1.132
Start Time: Thu, 13 Aug 2020 16:55:01 +0900
Labels: run=nginx
Annotations: <none>
Status: Running
IP: 10.96.0.3
IPs:
IP: 10.96.0.3
Containers:
nginx:
Container ID: docker://86bb0488af803a07157501380a262204ee3c4d2011de704b360dece11cd3d14f
Image: nginx:1.11.3
Image ID: docker-pullable://docker.io/nginx@sha256:d33834dd25d330da75dccd8add3ae2c9d7bb97f502b421b02cecb6cb7b34a1b6
Port: <none>
Host Port: <none>
State: Running
Started: Thu, 13 Aug 2020 16:55:01 +0900
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-5ptbc (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-5ptbc:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-5ptbc
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 4s default-scheduler Successfully assigned default/nginx to worker1
Normal Pulled 4s kubelet, worker1 Container image "nginx:1.11.3" already present on machine
Normal Created 4s kubelet, worker1 Created container nginx
Normal Started 4s kubelet, worker1 Started container nginx
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 19s
[root@master ~]#

無事podがRunningになった。StatusにあるIPアドレスでアクセスすると確かにnginxが動いている。

しかし、一体これはなんなのか。。。。

なお参考にさせていただいたのは以下のURL：
参考URL

とりあえず動くようになったけれども、結構行ったり来たりしたので備忘録メモ。

再起動前に以下を実行しておいかないとサービスが立ち上がらない。これが設定できていれば再起動でもKubernetes環境は健全に立ち上がる。
   systemctl enable kubelet.service

Joinしたノードを削除する方法。例としてworker1を削除するケース

1. 削除するノードへのスケジュール停止
   kubectl cordon worker1
2. ポッドがDeplyされていたら、その削除
   kubectl drain worker1 --ignore-daemonsets
3. ノードの削除
   kubectl delete node worker1

MasterにJoinする際のTokenを忘れた（有効期限切れ:24時間）の場合のToken再発行
   kubeadm token create --print-join-command

podの削除方法
　kubectl delete pod [pod-name]

PodのShellやコマンドの実行
チュートリアル

[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 5h7m
[root@master ~]# kubectl get pod nginx
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 5h7m
[root@master ~]# kubectl exec -it nginx -- /bin/bash
root@nginx:/# ls -l
total 8
drwxr-xr-x 2 root root 4096 Jul 27 2016 bin
drwxr-xr-x 2 root root 6 May 30 2016 boot
drwxr-xr-x 5 root root 360 Aug 13 07:55 dev
drwxr-xr-x 1 root root 66 Aug 13 07:55 etc
drwxr-xr-x 2 root root 6 May 30 2016 home
drwxr-xr-x 1 root root 30 Aug 23 2016 lib
drwxr-xr-x 2 root root 34 Jul 27 2016 lib64
drwxr-xr-x 2 root root 6 Jul 27 2016 media
drwxr-xr-x 2 root root 6 Jul 27 2016 mnt
drwxr-xr-x 2 root root 6 Jul 27 2016 opt
dr-xr-xr-x 238 root root 0 Aug 13 07:55 proc
drwx------ 2 root root 37 Jul 27 2016 root
drwxr-xr-x 1 root root 38 Aug 13 07:55 run
drwxr-xr-x 2 root root 4096 Jul 27 2016 sbin
drwxr-xr-x 2 root root 6 Jul 27 2016 srv
dr-xr-xr-x 13 root root 0 Aug 13 07:55 sys
drwxrwxrwt 1 root root 6 Aug 23 2016 tmp
drwxr-xr-x 1 root root 66 Aug 23 2016 usr
drwxr-xr-x 1 root root 19 Aug 23 2016 var
root@nginx:/# exit
exit
[root@master ~]#

[root@master ~]# kubectl exec nginx ps
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
PID TTY TIME CMD
1 ? 00:00:00 nginx
30 ? 00:00:00 ps
[root@master ~]# kubectl exec nginx ls /
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
bin
boot
dev
etc
home
lib
lib64
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var
[root@master ~]#

Contos7.7にKubernetesのインストールを行った。最終ゴールはCSIドライバの検証。その為のテストベンチの構築。

システムの前提：
メモリー 2GB
CPU 2コア。　2コア以上でないとkubeadmの初期化がエラーになるので重要。
但し、その実態はPlayer15.5.1上のゲストOSがESXi6.0の仮想マシーン。ペアレントOSはWindows 10。
ベースとなっているハードウエアはLenovo Minitower V530 (CPU i9-9900、Memory 32GB)

ステップ１：
/etc/hostname/に自分が設定したいhostnameを設定する。というのも、kubeadmで構成されるノード名はこのhostnameを使う為。放っておくとlocalhost.localdomainになってしまう。後から変更しようとすると大変みたい（一回試みたけれども、結局再インストールすることになったので）。

ステップ２：事前準備

Kubernetesではswapを無効化する必要があるようで、まずはそこから。

この状態ではswapは有効化されたまま。swapパーティションが設定されている。
[root@localhost ~]# cat /proc/swaps
Filename Type Size Used Priority
/dev/dm-1 partition 2097148 115456 -2

で、swapを無効化する。
[root@localhost ~]# swapoff -a

無効化されてるとswapパーティションの設定はなくなる。
[root@localhost ~]# cat /proc/swaps
Filename Type Size Used Priority
[root@localhost ~]#

恒久的にswapを無効化するにはfstabファイルを編集する。
以下編集前。
[root@localhost ~]# ls /etc/fstab -l
-rw-r--r--. 1 root root 465 8月 9 10:36 /etc/fstab
[root@localhost ~]# cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Sun Aug 9 10:36:36 2020
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/centos-root / xfs defaults 0 0
UUID=6530e066-08fd-43ef-923e-9d5bd349e51f /boot xfs defaults 0 0
/dev/mapper/centos-swap swap swap defaults 0 0
[root@localhost ~]#

以下、編集後。これで再起動してもswapは無効化されたままになる。
[root@localhost ~]# vi /etc/fstab
[root@localhost ~]# cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Sun Aug 9 10:36:36 2020
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/centos-root / xfs defaults 0 0
UUID=6530e066-08fd-43ef-923e-9d5bd349e51f /boot xfs defaults 0 0
# /dev/mapper/centos-swap swap swap defaults 0 0　　<<-この行をコメントアウトする
[root@localhost ~]#

firewallと止めておく。
[root@localhost ~]# systemctl disable firewalld
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
[root@localhost ~]# systemctl is-enabled firewalld
disabled
[root@localhost ~]# systemctl stop firewalld

SELinuxの動作を止める。
[root@localhost ~]# vi /etc/selinux/config
SELINUX=disabled << このように設定する

[root@localhost ~]# setenforce 0
[root@localhost ~]# getenforce
Permissive
[root@localhost ~]#

リブートしてもSELinuxがDisableのままであることを確認
[root@localhost ~]# getenforce
Disabled
[root@localhost ~]#
リブートしてもswapが復活しないことも確認。
[root@localhost ~]# cat /proc/swaps
Filename Type Size Used Priority
[root@localhost ~]#

ステップ３：dockerのインストール

[root@localhost ~]# yum install docker

[root@localhost ~]# systemctl start docker

dockerが動いているか確認。
[root@localhost ~]# docker network ls
NETWORK ID NAME DRIVER SCOPE
f8f5f6fe0aa5 bridge bridge local
2a4fafec0ac1 host host local
3b75d12b352c none null local

今回インストールしたバージョンは以下。
[root@localhost ~]# docker -v
Docker version 1.13.1, build 64e9980/1.13.1

bridgeネットワークを確認すると172.17.0.0/16を使っていることが分かるので、念のため自分の環境がこのIPアドレスを使っていないことを確認。
[root@localhost ~]# docker network inspect bridge
前略

"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16"
}
]
},
後略

ステップ４：　kubeadmのインストール
以下のrepoファイルを作成する。
[root@localhost ~]# vi /etc/yum.repos.d/kubernetes.repo
[root@localhost ~]# cat /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

kubeadmのインストール実行。
[root@localhost ~]# yum install kubeadm

完了しました!
[root@localhost ~]#

kubectlをインストール。けれども不要のようで。。。。
[root@localhost ~]# yum install kubectl
読み込んだプラグイン:fastestmirror, langpacks, product-id, search-disabled-repos, subscription-manager

This system is not registered with an entitlement server. You can use subscription-manager to register.

Loading mirror speeds from cached hostfile
* base: mirrors.cat.net
* extras: ftp.yz.yamagata-u.ac.jp
* updates: ftp.yz.yamagata-u.ac.jp
パッケージ kubectl-1.18.6-0.x86_64 はインストール済みか最新バージョンです
何もしません
[root@localhost ~]#

自動スタートするように変更
[root@localhost ~]# systemctl enable docker
Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /usr/lib/systemd/system/docker.service.
[root@localhost ~]#

[root@localhost ~]# systemctl enable kubelet.service

bridge-nf-call-iptablesを確認。
[root@localhost ~]# cat /proc/sys/net/bridge/bridge-nf-call-iptables
1だったら何もする必要がないが、0だったら以下を実行して1にする。そうしないとkubeadm initがエラーになる。
[root@localhost ~]# echo net.bridge.bridge-nf-call-iptables = 1 > /etc/sysctl.d/tmp-bridge-nf-call-iptables
[root@localhost ~]# sysctl -p /etc/sysctl.d/tmp-bridge-nf-call-iptables
net.bridge.bridge-nf-call-iptables = 1
[root@localhost ~]#
で、確認。
[root@localhost ~]# cat /proc/sys/net/bridge/bridge-nf-call-iptables
1
[root@localhost ~]#

[root@localhost ~]#

ここまでがMaster/Worker共有。以降はMasterのみ実行。

ステップ５：kubeadmの初期化

kubeadmの初期化の実行
ここで--pod-network-cidrは重要で、このアドレスレンジでpodにIPが割り当てられる。この設定値はあとでFlannelを設定するときに指定する値と同じにする必要がある。ちなみに10.244.0.0/16はFlannelのDefault値。この値にすればFlannelの設定を変更しなくても済む。
[root@localhost ~]# kubeadm init --apiserver-advertise-address=192.168.1.131 --pod-network-cidr=10.244.0.0/16

省略...

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.1.131:6443 --token 2x2256.gnt4vc4k35aj8ay7 \
--discovery-token-ca-cert-hash sha256:105ec7c037a732e7233055bc1aea53dca76fb10e72cfdf122937b58957c1d492
[root@localhost ~]#

Warningメッセージが出ていればちゃんとチェックして必要な対応をすること。WorkerがこのMasterにJoinするには出力の一番最後のkubeadm joinをWorkerで実行すること。

出力されたガイドに従って以下を実行。
[root@localhost ~]# echo $HOME
/root
[root@localhost ~]# mkdir -p $HOME/.kube
[root@localhost ~]# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[root@localhost ~]# chown $(id -u):$(id -g) $HOME/.kube/config

kubectlが動作していることを確認。
[root@localhost ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
master NotReady master 8m21s v1.18.6
[root@localhost ~]#
Pod間の通信ネットワークが開通していないので、StatusはNotReadyになっている。

ステップ６：Flannelのインストール

そこでFlannelのインストール。まずはymlファイルの確認。
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

[root@localhost ~]# vi kube-flannel.yml
編集前
net-conf.json: |
{
"Network": "10.244.0.0/16",　　<< ここがkubeadm initの--pod-network-cidr=で左記と違う値に設定した場合はその値を設定する。

"Backend": {
"Type": "vxlan"
}
}

ymlファイルの適用。
[root@localhost ~]# kubectl apply -f kube-flannel.yml

これでMasterノードはReadyになる、
[root@localhost ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
master Ready master 38m v1.18.6
[root@localhost ~]#

以上でMasterノードの設定は完了。

注意の追記：

Master/Workerとも次を実行しておかないと、再起動後にサービスが動かないので要注意。
# systemctl enable kubelet.service

以降はWorkerノードでの作業

Worker NodeをMasterにJoinさせる。

Kubeadm初期時に出力されたコマンドを使う。
# kubeadm join 192.168.1.131:6443 --token 8lscjp.6wdzj6n4w9svlwic --discovery-token-ca-cert-hash sha256:683d2a8ce762c8367f4cfa65b702bae1ef4b3d62623e706ac3042c9ea7cefd18 

ただし、kubeadm初期時のtokenの有効期間は24時間なので、それを過ぎると以下を実行して新しいTokenでのコマンドを取り直す必要がある。
# kubeadm token create --print-join-command

正しくJoinできてるか確認。
# kubectl get nodes

以上

自前のDNSを立てて、そのDNSを使うようにサーバーのresolv.confを編集したけれども、リスタートする度に誰かに上書きされてしまう現象。CentOS 7.7での出来事。インターネットでいろいろと調べて、結局以下の方法で解決（先人の知恵に感謝）。

まず、元に戻ってしまった（上書きされた）resolv.confは以下の通り。
[root@localhost ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.1.1
nameserver 2404:1a8:7f01:b::3
nameserver 2404:1a8:7f01:a::3

nmcliでネットワーク設定を見てみる。以下はens160の設定内容。IP4.DNSが設定されている。多分この値で上書きされてしまうのだろう（他に変更前の情報が保存されている場所が思いつかない）。
[root@localhost ~]# nmcli d show
前略
IP4.ADDRESS[1]: 192.168.1.131/24
IP4.GATEWAY: 192.168.1.1
IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 100
IP4.ROUTE[2]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 100
IP4.DNS[1]: 192.168.1.1
IP6.ADDRESS[1]: 240b:11:4541:9100:d349:93db:2bac:483d/64
IP6.ADDRESS[2]: fe80::ecaf:5d0c:edb4:12b/64
IP6.GATEWAY: fe80::221:d8ff:fe60:e3c8
IP6.ROUTE[1]: dst = 240b:11:4541:9100::/64, nh = ::, mt = 100
IP6.ROUTE[2]: dst = ::/0, nh = fe80::221:d8ff:fe60:e3c8, mt = 100
IP6.ROUTE[3]: dst = fe80::/64, nh = ::, mt = 100
IP6.ROUTE[4]: dst = ff00::/8, nh = ::, mt = 256, table=255
IP6.DNS[1]: 2404:1a8:7f01:b::3
IP6.DNS[2]: 2404:1a8:7f01:a::3
後略

NetworkManager.confを編集。[main]セクションにdns=noneを追記。
[root@localhost ~]# vi /etc/NetworkManager/NetworkManager.conf
前略
[main]
#plugins=ifcfg-rh,ibft

dns=none
[logging]
後略

NetworkMangerの再起動。
[root@localhost ~]# systemctl restart NetworkManager

この後、resolv.confを編集。
[root@localhost ~]# vi /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.1.250　<< これが私のDNSサーバー。毎回この行が消えていた。
nameserver 192.168.1.1
nameserver 2404:1a8:7f01:b::3
nameserver 2404:1a8:7f01:a::3
~
nmcliにてipv4.dnsエントリーを消去して、NetworkManagerを再起動する。
[root@localhost ~]# nmcli c mod ens160 ipv4.dns ""
[root@localhost ~]# systemctl restart NetworkManager

resolv.confが上書きされていないか確認。
[root@localhost ~]# cat /etc/resolv.conf
# Generated by NetworkManager
search flets-east.jp iptvf.jp
nameserver 192.168.1.250　　　<< 残っている
nameserver 192.168.1.1
nameserver 2404:1a8:7f01:b::3
nameserver 2404:1a8:7f01:a::3
[root@localhost ~]#

nmcliにて現状を確認。ens160からIP4.DNSが消えている。これで上書きされる元データがなくなった（多分）。
[root@localhost ~]# nmcli d show

IP4.ADDRESS[1]: 192.168.1.131/24
IP4.GATEWAY: 192.168.1.1
IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 100
IP4.ROUTE[2]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 100
IP6.ADDRESS[1]: 240b:11:4541:9100:d349:93db:2bac:483d/64
IP6.ADDRESS[2]: fe80::ecaf:5d0c:edb4:12b/64
IP6.GATEWAY: fe80::221:d8ff:fe60:e3c8
IP6.ROUTE[1]: dst = 240b:11:4541:9100::/64, nh = ::, mt = 100
IP6.ROUTE[2]: dst = ::/0, nh = fe80::221:d8ff:fe60:e3c8, mt = 100
IP6.ROUTE[3]: dst = fe80::/64, nh = ::, mt = 100
IP6.ROUTE[4]: dst = ff00::/8, nh = ::, mt = 256, table=255
IP6.DNS[1]: 2404:1a8:7f01:b::3
IP6.DNS[2]: 2404:1a8:7f01:a::3

この状態でDNSに登録さてれいるサーバー名でnslookupを実行すると、ちゃんとResolveされた。

これで大丈夫みたい。

HDMIで接続されているPCモニターにスピーカーがない。なのでオーディオはイヤホンジャックで聞くことになる。
Raspberry Piのオンラインドキュメントをみると以下のコマンドを実行せよとある。しかしエラーになる。

pi@raspberrypi:~ $ amixer cset numid=3 0
amixer: Cannot find the given element from control default

pi@raspberrypi:~ $
確かにnumid=3がない。numid=3はPCM Playback Routeである、とオンラインドキュメントには書かれている。つまりサウンド出力先を切り替えるわけだ。

pi@raspberrypi:~/raspi/raspi1-sample $ sudo amixer controls
numid=2,iface=MIXER,name='HDMI Playback Switch'
numid=1,iface=MIXER,name='HDMI Playback Volume'

pi@raspberrypi:~ $ amixer cget numid=1
numid=1,iface=MIXER,name='HDMI Playback Volume'
; type=INTEGER,access=rw---R--,values=1,min=-10239,max=400,step=0
: values=0
| dBscale-min=-102.39dB,step=0.01dB,mute=1
pi@raspberrypi:~ $ amixer cget numid=2
numid=2,iface=MIXER,name='HDMI Playback Switch'
; type=BOOLEAN,access=rw------,values=1
: values=on
pi@raspberrypi:~ $ amixer cget numid=3
amixer: Cannot find the given element from control default

raspi-configで設定変更できる感じだけれど（メニューにあるから）変更はできなかった。

これはオンラインドキュメントに記載されてない何かがあるようだ。となると、Pi 4Bを買った人は同じ状態になっているはず。で、早速グーグル検索。ありました。
stackoverflow
下のリンクを読むこと、とある。
Raspberry Pi Blog
これによると、いままでは一つのALSA（Advanced Linux Sound Archiecture）デバイスの中でサウンドルートを切り替えていたのを、デバイスごと分けたそうだ。理由は、この実装方法は結構特殊で、３rdパーティーソフトウエアのサポートが得られないから、とのこと。で、新しいバージョンではDesktop上のメニューバーの右端にあるスピーカーアイコンを右クリックするとサウンドデバイス選択ができるとのこと。たしかにAnalogとHDMIの選択肢がある。このDesktop上でのサポートによってCLIによるサポートは終了しているとのことだ。

mpg321をインストールして、mpgファイルを再生してみた。mpg321の所為なのか、ブツブツとノイズが入るものの、ヘッドホーンジャックでサウンドが再生できた。
pi@raspberrypi:~ $ sudo apt-get install mpg321

ちなみに現在の環境は以下の通り。

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

pi@raspberrypi:~ $ cat /etc/debian_version
10.4

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.4.51-v7l+ #1327 SMP Thu Jul 23 11:04:39 BST 2020 armv7l GNU/Linux

pi@raspberrypi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
pi@raspberrypi:~ $

なかなか道のりは長そう。

ラズパイのインストールが終わった最初の週末、早速自習開始。

秋月電子から届いていたパーツを開封。このパーツはブルーバックスの実習用のパーツセット。結構中身は充実しているけれども3500円ととてもお値打ち。とにかくPythonコードを含めて一通りの機能がこれで試せるのでありがたい。

随分と長いこと空だったパーツボックスに部品を収容。カラーコードを見ながら、”小林一茶”、”第三の男”、”黒いレイ服”などと昔の記憶から蘇る。

LED点灯デモ。タクトスイッチの立ち上がりエッジで割込みをかけて、LED点灯・消灯をトグル切り替え。GPIOのインプットとアウトプットの基本形、インプットの内蔵プルダウン抵抗のイネーブル、アウトプットの初期設定、状態設定の解除（状態が設定されている状態のGPIOを再設定しようとするとコンフリクトエラーがでる）などをここで学ぶ。

ここから先も実習があるけれどもパーツを組み立てないといけない。これには半田付けが必要。先端が細いICなどが半田付けできる半田ごてと、拡大鏡が必要。こちらもアマゾンで注文。

ステップ１はここまで。