在Kubernetes1.7上试图将Rancher1.6的PV转换为azurefile的故事
我是一个完全不懂使用Docker的初学者。我会尽可能写一些我所能达到的内容，希望不会造成麻烦。最近Azure似乎非常流行，所以我也跟风一下，但个人并没有其他意思，只希望能够用得上就好了。
目的和背景等
因为有试着勉强去做一些事情的打算，所以本来只打算在rancher上运行gitlab之类的，但是后来被告知要做prometheus，所以也要去做。关于prometheus的设置和协作方式有很多，虽然在rancher的目录中可以找到与grafana协作的选项，但alertmanager的功能却没有包含在该目录中。对于自制和定制目录的方法，我稍微试了试但完全没成功，也不知道解决办法。而且该目录的设置文件本身对我来说很难理解（不需要构建而只是想更新设置文件？为什么呢？）。所以我考虑使用helm在kubernetes上使用，根据helm的稳定政策看起来不错。
然后，成功将AzureFile作为持久卷，但是helm客户端无法连接到位于https的nginx-proxy后面的tiller服务器？所以无法使用helm来操作kubernetes集群。但通过Rancher的GUI界面上的kubectl用CLI界面执行helm init;helm repo update等命令可以执行helm。虽然每次都要重新加载页面才能连接上，但也不需要每次都进行初始化操作，所以还好。←当前位置
（有人写道将ELB的监听协议从HTTPS改为SSL就能轻松解决的）
我不能在周围找到会说”Doraemon，帮帮我！”的人，所以只能追求常规的yaml清单编写，不使用Rancher进行部署，而是自己构建（可能会很困难）或者使用托管服务可能会更容易（可能不能使用托管服务，因为这可能只是为了学习）。
因为很少有人尝试使用AzureFile在kubernetes中使用PV和PVC，所以我写下来作为参考。
顺便一提，从Rancher来看，目前1.6版本似乎还不能将cifs和samba（azurefile）作为存储驱动使用（我在搜索时好像看到了相关的PR）。
Kubernetes术语备忘录等
因为公司碰巧有WEB+DB的第99期，听说很不错，我借来看了一下。根据解释，大致就像是传统的坐下来学习那种感觉。（还有，可能是因为拼写太长的原因，很多人都简写成了”k8s”）
-
- Podは同一ノードで動くコンテナのセットでPodごとにIPが振られる。apiとwebやリバプロとwebを一緒にしとく
-
- Labelをはっとくと検索して同じラベルのリソースがグルーピングされてそれに同じ処理をするとかできる
-
- Serviceは複数のpodがぶら下がった外部からのアクセスを制御するエンドポイントでいくつかの種類がある
-
- （ClusterIPはDNS、NodePortはポートマッピング、LoadbalancerはIngress、ExternalNameはCNAMEレコード、HeadlessはStatefulsetにつかう内部DNSっぽいのという理解）
-
- IngressはpodへのアクセスをHTTPプロキシするやつでTLSもいけるらしい
-
- Volumeはデータの格納領域で幾つか種類があるが複数ノードからのアクセスを可能にしておく永続的なものが推奨される
-
- （emptyDirVolumeはホストの領域をつかうがPodが削除されると消える、hostPathVolumeはホストのマウントパスを明示的に指定するがホストが消えると消えてしまう
-
- PersistentVolume(PV)を作っといてPersistentVolumeClaim(PVC)でPVリソースからどれだけ利用するかを指定する。（そうするとデータの永続化ができる、PVとPVCは1対1の紐づけのみ）
-
- 動的なプロビジョニングの場合にはStorageClassという仕組みを利用してプロビジョニングをする。StorageClass名をPVC側で指定するとよきようにマッピングしてくれる
-
- ConfigMap/Secretで設定をコンテナイメージから切り離す。それをつかうにはVolumeとしてマウントするか環境変数に設定するなどの方法がある
-
- podそのものは自分の状態を管理することができないので各コントローラというリソースを用いる
-
- ReplicaSetは水平スケーリング用のコントローラで複数の同一の内容のpodをいくつつくるかを管理する
-
- DeploymentはイメージをBGデプロイしてデフォルト1世代のこしといて切り戻しができるコントローラ
-
- HorizontalPodAutoscalingによる自動水平スケーリングではCPU負荷(2017/7月時点)の増減により処理を行う
-
- DaemonSetは各ノードに1コンテナずつ配置するコントローラでFluentdやPrometheusのNodeExporterなどが例としてある
-
- Statefulsetはその名の通りデータ持ってるやつでIDが順繰り振られてその順に起動するので0をマスタにするDBコンテナに適してる。削除後に同じIDのpodが起動するし全く同じボリュームが割り当たる
- Job/CronJobはタスクの実行を行うものでPodからの成功通知を待って終了するのとparallismの数だけpodが作成される
准备AzureFile
需要创建一个存储帐户，并记下帐户名和密钥，然后创建一个 Azure 文件容器。
你可以在门户网站上点击点击，也可以使用 az 命令搜索，门户网站的用户界面很直观，所以即使不搜索也可以完成，我只是提到需要准备这一点。
注册Secret
请先将存储帐户信息注册到秘密中。
# mkdir /home/docker/k8s;cd /home/docker/k8s
# echo -n 'ストレージアカウントのKEY' > azstorage-secret.txt
# kubectl create secret generic azstorage-secrets \
--from-file=azurestorageaccountkey=azstorage-secret.txt \
--from-literal=azurestorageaccountname=${mystrageaccount}
以前，我尝试将字符串加密为Base64，然后写入YAML并进行注册，但这种方法并没有成功。我想可能是因为我还需要将存储帐户名称进行加密，才能看到正确的输出（我没有进行验证）。
在创建时，如果添加了–namespace monitor这样的命令，就可以将资源分配到特定的命名空间中，这样可以使命令行界面或仪表盘中的显示更加清晰易读。如果不指定命名空间，默认情况下会从secret重新注册。我记得有人提到可以按存储库的单位进行分割。
确认已注册的事项。
# kubectl get secrets azstorage-secrets -o yaml
apiVersion: v1
data:
azurestorageaccountkey: ***********L3c9PQ==
azurestorageaccountname: *****hdGlvbg==
kind: Secret
metadata:
creationTimestamp: 2017-12-08T07:09:02Z
name: azstorage-secrets
namespace: default
resourceVersion: "8462"
selfLink: /api/v1/namespaces/default/secrets/azstorage-secrets
uid: abd5529c-dbe6-11e7-9680-02de519233a2
type: Opaque
查看k8s的仪表盘发现秘钥增加了。
有人编写了一个Pod的yaml文件，在将Azure存储帐户信息注册后，似乎可以立即将其指定给卷，从而可以从Pod中挂载。他们还提供了WordPress的示例。
当查看这里存储的列表时，发现有一个名为AzureFile的选项，可以从多个节点进行读写操作，即ReadWriteMany。当查看在AzureFile节点上执行mount命令的返回值时，rsize=1048576，wsize=1048576等等。
创建持久卷(PersistentVolume)
我来试着使用Azure文件创建永久卷。NFS的方法我在这里看到过。
# vi azfile-pv.yaml
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv001
labels:
name: pv001
spec:
capacity:
storage: 1024Gi
accessModes:
- ReadWriteMany
azureFile:
secretName: azstorage-secrets
shareName: k8s-data
readOnly: false
# kubectl create -f azfile-pv.yaml
persistentvolume "pv001" created
用三个连字符分隔，包括 PVC ，一起写并创建也可以。
注意事项是 accessModes 在 PV 和 PVC 中都不匹配时，创建 PVC 时状态会停留在 Pending ，无法使用，并且不会显示在仪表板上。
如果有多个卷，给 PV 添加标签，然后可以从 PVC 中选择指定。
标签/选择器可能会用于其他路由等方面。
PV 和 PVC 只能是一对一的关联。
创建持久卷声明（PersistentVolumeClaim，PVC）。
永久存储卷请求是如术语中所述的对于永久存储卷的请求。将其作为Pod的yaml文件中的卷进行指定。
# vi azfile-pvc.yml
# cat azfile-pvc.yml
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: azfileclaim01
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 8Gi
selector:
matchLabels:
name: pv001
# kubectl create -f azfile-pvc.yml
persistentvolumeclaim "azfileclaim01" created
创建一个存储类试试看
因為儀表板上出現了警告，所以我暫時做了一個（好像在製作PV時，無論是否指定都可以，但在指定PVC時，似乎可以自動分配）。
# vi azstorageclass.yml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: azurefile
provisioner: kubernetes.io/azure-file
parameters:
skuName: Standard_LRS
location: japanwest
storageAccount: mystorageaccount
# kubectl create -f azstorageclass.yml
storageclass "azurefile" created
在编写PV或PVC时，需在其中添加一行`storageClassName: azurefile`。
通过CLI或仪表盘进行确认。
# kubectl get persistentvolumeclaims
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
azfileclaim01 Bound pv001 1Ti RWX 6s
# kubectl get persistentvolume
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs 20Gi RWX Retain Bound default/nfsclaim01 1d
pv001 1Ti RWX Retain Bound default/azfileclaim01 7d
尝试使用PVC建立Pod，并确认可以从AzureFile查看更新数据。
# vi /opt/rc-azfile.yml
kind: Pod
apiVersion: v1
metadata:
name: rc-azfile-test
labels:
app: nginx
spec:
volumes:
- name: azurefile
persistentVolumeClaim:
claimName: azfileclaim01
containers:
- name: nginx
image: nginx
ports:
- name: nginx
containerPort: 80
volumeMounts:
- name: azurefile
mountPath: "/usr/share/nginx/html"
# kubectl create -f /opt/rc-azfile.yml
pod "rc-azfile-test" created
# kubectl get pods
NAME READY STATUS RESTARTS AGE
rc-azfile-test 1/1 Running 0 45m
可以使用k8s或Rancher仪表盘，或者使用docker命令，进入容器并执行df命令，可以看到似乎已经成功挂载。
root@rc-azfile-test:/# ls
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
root@rc-azfile-test:/# df -h
Filesystem Size Used Avail Use% Mounted on
none 30G 4.0G 26G 14% /
tmpfs 1.7G 0 1.7G 0% /dev
tmpfs 1.7G 0 1.7G 0% /sys/fs/cgroup
/dev/sda1 30G 4.0G 26G 14% /etc/hosts
shm 64M 0 64M 0% /dev/shm
//mystorageaccount.file.core.windows.net/k8s-data 1.0T 64K 1.0T 1% /usr/share/nginx/html ←★これ
tmpfs 1.7G 12K 1.7G 1% /run/secrets/kubernetes.io/serviceaccount
如果在这里创建了一个文件，就可以从AzureFile的门户界面下载。最好是划分子目录。
我觉得头盔看起来很方便。
虽然我很遗憾失败了，但我认为Helm的稳定版本似乎相当方便。
– 提供了数据持久化的方法
– 支持应用程序升级
– 允许自定义应用程序配置
– 具有安全的默认设置
– 不使用Kubernetes的Alpha功能
看起来很容易使用。
请点击这里查看如何正确佩戴头盔。
如果helm可以使用，我想尝试执行以下命令。暂时停用https并进行分离可能吗？
以下是例子。如果没有准备匹配访问模式的PV和PVC，exporter等会出现，但Prometheus和alertmanager服务器不会启动，所以必须准备匹配访问模式的PersistentVolume和PersistentVolumeClaim。在搜索Prometheus侧的PVC错误时，发现了类似于文件共享被锁定的问题。所以似乎只能使用类似host_path的方法。通过helm status可以查看正在运行的数量，但在kubernetes仪表板上会变成红色，并且错误消息很清楚。此外，个人认为rancher更容易追踪过去的日志。
> helm install stable/prometheus --name monitor --namespace monitor --set \
> persistence.enabled=true,alertmanager.persistentVolume.existingClaim=alertmanager-claim-rwm,alertmanager.persistentVolume.accessModes=ReadWriteMany,server.persistentVolume.existingClaim=prom-pv-claim,server.persistentVolume.accessModes=ReadWriteOnce
顺便说一下，hostpath的持久卷（PV）和持久卷声明（PVC）看起来应该是这样的感觉。hostpath会将容器挂载到主机上，所以在主机崩溃之前应该没问题，但只能从一个主机访问。现在主机都是一次性使用的，而且有形的东西总会损坏，所以可能需要数据备份。
# cat prom-hostpath-pv*
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: prom-pv-claim
namespace: monitor
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: prom-hostpath-pv
labels:
type: local
namespace: monitor
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
hostPath:
path: /var/lib/prometheus
# type: DirectoryOrCreate
# kubectl create -f prom-hostpath-pv.yml
# kubectl create -f prom-hostpath-pvc.yml
# kubectl --namespace=monitor get pv,pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv/prom-hostpath-pv 5Gi RWO Retain Bound monitor/prom-pv-claim 35m
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc/prom-pv-claim Bound prom-hostpath-pv 5Gi RWO 35m
如果从Rancher GUI的kubectl用CLI的节点以外执行，将会出现以下类似的错误。如果有人知道解决办法，请告诉我。非常感谢！
# helm version --debug
[debug] Created tunnel using local port: '38139'
[debug] SERVER: "127.0.0.1:38139"
Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
E1215 22:59:36.901993 31974 portforward.go:271] error creating error stream for port 38139 -> 44134: Timeout occured
[debug] rpc error: code = Internal desc = transport is closing
Error: cannot connect to Tiller
# kubectl -n kube-system get po
NAME READY STATUS RESTARTS AGE
heapster-76b8cd7b5-7qvbl 1/1 Running 0 7d
kube-dns-5d7b4487c9-4wzsn 3/3 Running 0 7d
kubernetes-dashboard-5ffb9c9bb7-9jczl 1/1 Running 0 7d
monitoring-grafana-997796fcf-wpwtr 1/1 Running 0 7d
monitoring-influxdb-56fdcd96b-k85vt 1/1 Running 0 7d
tiller-deploy-79c88c5d98-n7qgm 1/1 Running 0 7d
另外，根据我查阅和使用 Prometheus 和 Alertmanager 目录来启动和添加服务，最初的印象是 Grafana 的显示非常漂亮，而且有很多预设的指标和出口程序，可以很好地汇总通知。但是，由于配置只能使用 YAML 格式，没有图形用户界面，这可能会导致监控操作员的协作操作变得困难且需要相当一定的工作量，这会使得操作依赖有经验的工程师，对于运维来说可能成为一个相当耗时的任务。
将rancher环境迁移到kubernetes并进行启动后，我们注意到的一些问题等。
・如果设置了访问控制，则必须在Rancher上进行登录验证，否则不能在注销状态下操作Kubernetes仪表板（有认证关联）
・初次启动时，必须将环境切换到Kubernetes并注册主机，否则可能无法成功。
・在现有集群中从Rancher的Kubernetes环境中添加节点，将在Kubernetes仪表板上显示。
・仅仅启动Kubernetes集群的主节点或节点是不够定义的。
・由于Rancher 2.0预览版中认证功能无效，因此如果要认真使用，就必须在类似Nginx的反向代理中添加认证功能。使用AzureAD时，感觉需要在Nginx中自定义构建并启用sub_filter模块。
・我觉得Rancher的用户界面更易于使用，但是Kubernetes仪表板上大部分可以通过Rancher完成的事情我觉得也可以做。虽然我对两者都不是很熟悉，但是像连接到容器或查看日志之类的操作两者都可以进行。
・Kubernetes仪表板几乎无法进行手动更新，主要通过kubectl和yaml进行各种操作，而Rancher可以通过图形界面轻松操作，然后保存相应的yaml文件进行备份。这是我认为的区别。尽管先后顺序不同，但两者都考虑了可视化的需求。
请参考
・与Azure相关的容器服务：将Azure文件存储用作持久化（Kubernetes）卷 – Karim Vaes
使用Docker和Kubernetes构建”具有强大适应能力的基础架构” |Wantedly工程师博客
使用Rancher在Kubernetes上使用Helm和Docker运行Jenkins的方法 – Qiita
配置Pod以使用PersistentVolume进行存储 | Kubernetes
Persistent Volume | Kubernetes
Kubernetes入门内容汇总 – Qiita
第二章 Kubernetes入门指南
想要学习Kubernetes // Speaker Deck
构建Kubernetes集群环境并尝试通过Dashboard进行可视化 – Taste of Tech Topics
故障排除| Kubernetes Engine 文档 | Google Cloud Platform
https://qiita.com/apstndb/items/9d13230c666db80e74d0
Kubernetes 有时候是无服务器的 — cndjp第1回研讨会
生产环境中的Kubernetes！ — cndjp第2回
【IBM Cloud k8s验证备忘录】识别并挂载两个或更多持久化存储 – Qiita
・Helm相关
Kubernetes: 包管理器Helm – Qiita
使用Helm在Azure Kubernetes上部署容器 | 微软文档
helm/install.md主分支 · kubernetes/helm
charts/stable/prometheus主分支·kubernetes / charts
Ladicle/kubernetes-helm-jp-doc: Kubernetes Helm日文文档
Rancher中的Kubernetes插件
・关于Prometheus
使用Prometheus进行简单的服务器监视- Qiita
关于Alertmanager的介绍- wyukawa的博客
出口和集成| Prometheus
AbemaTV的监视- SSSSLIDE
关于在AbemaTV中引入名为Prometheus的监控系统的讨论
