Closed cosven closed 3 years ago
我想在本地操作一个远程 K8s 集群,但是我没有 kubeconfig,我想解决这个问题,虽然我完全可以不再本地进行操作。
1. kubectl 使用的到底是哪个配置?为啥在 node 本地使用 kubectl 没一点问题?
API 请求被绑定到普通用户或 serivce account 上,或者作为匿名请求对待。 这意味着集群内部或外部的每个进程,无论从在工作站上输入 kubectl 的人类用户到节点上的 kubelet, 到控制平面的成员,都必须在向 API Server 发出请求时进行身份验证,或者被视为匿名用户。
Controlling Access to the Kubernetes API
The previous discussion applies to requests sent to the secure port of the API server (the typical case). The API server can actually serve on 2 ports:
By default the Kubernetes API server serves HTTP on 2 ports:
- Localhost Port
- Secure Port
解释了为什么 kubectl 可以在本地使用(只能在 master 节点)。
2. 怎样生成一个 kubeconfig 呢,让我可以从远程来控制一个集群呢?
https://kubernetes.io/docs/reference/access-authn-authz/authentication/
All Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users.
Both human users and Kubernetes service accounts can be authorized for API access.
Authentication strategies 里面提到一个 OpenID Connect Tokens,我知道另外一个集群使用的就是这种方法。
参考这个文档可以解决生成 kubeconfig 的疑问,然后使用 RoleBinding 控制权限。
阅读 创建TLS证书和秘钥 来了解 TLS 证书相关概念
配合阅读 那些证书相关的玩意儿(SSL,X.509,PEM,DER,CRT,CER,KEY,CSR,P12等)
没有阅读完这些资料,大概的理解:先自己生成一套 CA(包含公钥,私钥啥的),然后基于这套 CA 生成其他的证书,比如 kube-proxy/admin 用的。
所以,生成 kubeconfig 的过程大致如下:
我想动手尝试的时候,发现我们的证书这一套东西似乎不使用 cfssl 生成的,因为我没看到 ca-config.json 类似的文件。然后我看到了一个 kubeadm 相关的东西,所以我想我是不是要换个思路?
于是有了第四个问题 -> jump
3. Kubernetes 是怎样管理权限的呢?
Configure Service Accounts for Pods
When you (a human) access the cluster (for example, using kubectl), you are authenticated by the apiserver as a particular User Account (currently this is usually admin, unless your cluster administrator has customized your cluster). Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account (for example, default).
先不管这个问题,我觉得可以认为是 RABC 管的把,虽然可能里面会更加复杂。
4. kubeadm 怎样生成 kubeconfig?
workaround: 可以先把 /etc/kubernetes/admin.conf 拷贝过来用,当自己是 admin 用户。
??
有一个集群用了 helm,TiDB-Operator 也用了 helm,所以我要学着用。
嗯,果然,这里 有相关的 helm 使用姿势。
一些常用的命令
helm status name
helm desktroy name --purge
我感觉这个标题应该从 「helm 初次使用」改成「TiDB-Operator 初次使用」。
Deployment 和 ReplicaSet 都是 Controller,可以进行 scale,但 Pod 不可以。
参考链接:https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
Docker For Mac 中的 docker 的宿主机是一个虚拟机,而不是 macOS。
参考:https://docs.docker.com/docker-for-mac/networking/
通过这个域名 host.docker.internal
可以访问到 macOS。
根据 TiDB-Opeartor 文档描述,我更新 values.yaml 里面配置的镜像版本或者 replica 数,都是可以触发 upgrade 的。但是我怎样让 helm 检测到我添加了一个 drainer 呢?
简单看了 charts 中 templates 和 config,感觉如果要触发 helm 的 upgrade,需要让这两个模板生成的文件发生变化。所以我是不是得加个 template 或者 config?它的 template 和 config 是什么呢?
template 对应 Kubernetes service/deployment/configmap 等概念,而 config 是被 Kubernetes configmap 使用。
我还注意到文件夹中还有 scripts 文件夹?scripts 中的内容会以文本的形式注入到 template 中的 cmd 字段中去,利用了 yaml 的 block text 功能把。
其实我只要利用 helm 生成 yaml,然后我就可以自己操作了。
但是这种方案不是最佳,还是利用 helm 会比较方便,所以我得自己编写 helm ... chart
但是我不想写 chart,风险大呀,能不能只安装一个呀,毕竟我只要安装 drainer。 话说 helm 是怎样判断 drainer 的安装顺序呢,看起来 drainer-statefulset 依赖了 configmap,而 statefulset 又依赖了 service。
查了下:https://stackoverflow.com/a/51962615/4302892 说 helm 会按照一定的顺序来安装这些资源。
仅仅是 yaml 更新了,helm 貌似也不一定会 upgrade。比如更新 configmap 中的 data。
暂时先使用 kubectl edit
手动更新后解决。
所以 configmap 的 data 字段是什么呢?
可以指定,但也可以不指定。不指定的时候应该是随机的把。
由于镜像里面不方便放入配置,所以有了 configmap 把。
创建 configmap :使用 kubectl create configmap --from-file xxx
使用 configmap:
apiVersion: v1
kind: Pod
metadata:
name: arbiter
labels:
longroad: arbiter
spec:
containers:
- name: arbiter
image: arbiter:3.0.1
args: ["-config", "/etc/config/config-arbiter.toml"]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: arbiter
brew 安装特定版本的 kubernetes-helm: https://github.com/helm/charts/issues/5239#issuecomment-423357321
一个项目里面包含多个组件,怎样组织这个项目比较好?是像 TiDB-Operator 一样全部摊平放,还是树形结构?
我的目标是:
探索步骤:
使用 kubebuilder 2.0beta + kustmize 3.0.3 遇到 https://github.com/kubernetes-sigs/kustomize/issues/1373 这个问题。
make deploy 记录:
kustomize build config/default | kubectl apply -f -
namespace/longroad-system created
customresourcedefinition.apiextensions.k8s.io/guestbooks.webapp.pingcap.com configured
role.rbac.authorization.k8s.io/longroad-leader-election-role created
clusterrole.rbac.authorization.k8s.io/longroad-manager-role created
clusterrole.rbac.authorization.k8s.io/longroad-proxy-role created
rolebinding.rbac.authorization.k8s.io/longroad-leader-election-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/longroad-manager-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/longroad-proxy-rolebinding created
service/longroad-controller-manager-metrics-service created
deployment.apps/longroad-controller-manager created
逆序 kubectl delete -f
由于我先 kubectl delete -f config/base
,后面遗留了该类型资源,无法删除。
我是一个 Kubernetes 小白,之前从事 DevOps 相关工作,有近 3 年的 Python 开发经验,现在是 QA 工程师。
我之前有简单学习过 Kubernetes,了解 Pod 等概念,会使用 kubectl 来进行一些简单操作;简单了解 Docker 原理;对 Golang 基本没啥了解。
这里记录我自己以一个 QA 工程师的身份 来学习这样一个新系统的过程。
我想从这个过程中找到一些问题的答案:
一些标记: