ETCD读取的辅助脚本

etcd v3版本的api不能像zk那样访问目录了，需要做一些调整，以下是相关脚本：

#!/bin/bash
# etcdctl_v3
ETCDCTL_API=3 /usr/bin/etcdctl-3.1.2 --endpoints=https://127.0.0.1:2379 --cacert=ca.pem --cert=kubernetes.pem  --key=kubernetes-key.pem $@


#!bin/bash
# get sub path of kubernetes in etcd
keys=`./etcdctl_v3 get /registry --prefix -w json|python -m json.tool|grep key|cut -d ":" -f2|tr -d '"'|tr -d ","`
for x in $keys;do
          echo $x|base64 -d|sort
done

一下clientgoclientset 与 internelclientset的区别在哪里？

关于MemoryVersion、StorageVersion的区别以及作用？

实际上apiserver操作的都是internal version，在这里就是MemoryVersion。举个例子，假如有一个创建Pod的请求来了，apiserver首先会将请求给反序列化，用户发过来的pod请求往往是有版本的,比如为v1，因此会反序列化为一个v1.Pod。apiserver会立即将这个v1.Pod利用convertor转换成internal.Pod，然后进行一些操作，最后要把它存到etcd里面去，etcd里面的Pod信息是有版本的，版本信息存储在StorageVersion中，对于Pod而言一般是v1版本，因此会先发生一次转换，将其转换为v1.Pod,然后序列化存入etcd。这样看上去是不是多此一举?其实这就是k8s对api多版本的支持，这样有什么好处了，用户可以以一个v1betal创建一个Pod，然后存入etcd的是一个相对稳定的版本，比如v1版本。转换必定存在着效率的问题，为了解决效率问题，转换函数由开发者自己写，然后会重新用代码生成一边。具体的优化原理还不清楚。