云原生下的开发测试调试IDE

Posted 2021-04-29 高效研发测试

背景

    在容器技术高度流行的当下，Kubernetes盛行。
那么作为开发测试又是如何去快速上手或者以某种方式这门新技术呢， 除了无聊的培训，看资料，我们是否需要一个趁手的武器来
丰富我们的 技能包？

答案是肯定的。

怎么玩？ 用什么？ 话不多说。 VSCODE! Kubernetes！

完了。。

玩法

• VSCode 插件管理器 搜索 Kubernetes, 安装， 重载

• 这时候你的VS 左树应该有个 K8S的图标了

• 这时候你点击下图标貌切到了一个界面但是没啥反应, 右下角提示要你安装一些东西 kubectl 什么的，嗯这些是需要安装的

• 这时候你发现好像装不了， 没事，伟大的墙总是要折腾下你的，自行给vscode 配置一个 http.proxy即可。这几个工具一定要安装哦。

玩了吗? 没玩起来

这时候你需要配置？ 怎么配？

来配置下：

这里注意下 kubeconfig这一行，熟悉的人知道这是集群的配置，我们先指定下集群的 管理config（admin.conf）尝尝鲜。

保存下，点击K8S图标看下效果:

是不是帅炸？

完了吗

只是教你这点东西，恐怕你根本不会把这个神器教给开发测试同学，

我的天总不能让我运维把 集群admin.confi给你开发测试当玩物吧。。。。。

这里告诉你，某种程度上无论你们公司平台怎么折腾，是把namespace当做项目也好，还是把namespace作为项目下的一个分区也好，你都必须实现一个生成用户kubeconfig的服务。原理很简单;

怎么做？ 简单的做可以这样做

第一步: 给你的用户赋权

Kubernetes RBAC 内置 两个 cluster role； edit, view

这两个角色顾名思义， 查看，编辑角色

你可以动态的(基于API)给用户赋予某个namspace的权限 (即RoleBinding)
具体参考一段py代码:

            if action == "add":
                result = k8s.rbac.create_namespaced_role_binding(namespace,
                                                                 {
                                                                     "metadata": {
                                                                         "name": "{}-{}-{}-rolebinding".format(username,role,namespace)
                                                                     },
                                                                     "roleRef": {
                                                                         "apiGroup": "rbac.authorization.k8s.io",
                                                                         "kind": "ClusterRole",
                                                                         "name": role
                                                                     },
                                                                     "subjects": [
                                                                         {
                                                                             "apiGroup": "rbac.authorization.k8s.io",
                                                                             "kind": "User",
                                                                             "name": username
                                                                         }
                                                                     ]
                                                                 })

            else:
                result = k8s.rbac.delete_namespaced_role_binding("{}-{}-{}-rolebinding".format(username, role, namespace),
                                                                 namespace, {})

这是第一步，第二步你需要为用户生成kubeconfig， 这一步要求我们需要使用集群的ca 为用户颁发证书，其实很简单，颁发证书的代码我也贴上来算了。

            # 制作证书
            key = crypto.load_privatekey(crypto.FILETYPE_PEM, cluster.cluster_ca_key)
            crt = crypto.load_certificate(crypto.FILETYPE_PEM, cluster.cluster_ca)
            pkey = createKeyPair(crypto.TYPE_RSA, 2048)

            req = createCertRequest(pkey, CN=username)
            # 签个50年，50年后又是一条好汉
            cert = createCertificate(req, (crt, key), 1, (0, 60 * 60 * 24 * 365 * 50))
            user_key = base64.b64encode(crypto.dump_privatekey(crypto.FILETYPE_PEM, pkey)).decode("utf-8")
            user_cert = base64.b64encode(crypto.dump_certificate(crypto.FILETYPE_PEM, cert)).decode("utf-8")

然后说明下 kubeconfig文件构成，kubeconfig本身是支持 多cluster多Namespace的。

重点说明下 多集群的时候，每个集群的ca证书对可能不一样，于是对单个用户来说，两个集群的访问凭据也不一样，kubeconfig中的User.name 仅仅是一个key而已。 所以同一个用户在集群11中，kubecongfig的username可能为 ybyang2-cluster-11,但是真正有效的用户名是ybyang2 是签发在用户凭据的证书中，所以kubeconfig中的username其实无关紧要，只要在config的上下文中能正确引用即可。其他诸如 context.name, cluster.name 同理

简单贴下实例api图:

如图所示 是API生成同一用户对两个集群的 的一个 kubeconfig文件。。。
那么 这个用户在 vscode配置这个上这个kubeconfig后 将只能操被限制的命名空间。并且它的权限随时受apiserver全局控制(我们这里是edit,view由项目管理员分配)

效果如下。

其实这就是k8s的的一个简单的多租户玩法，基于vscode，我们让我们的开发者更加的云原生，也更容易让开发运维和测试在保证集群的稳定前提下学习k8s的概念，部署应用到k8s。