K8S之按官方Dashboard目录来进行名词扫盲实战

爽朗地狮子 • 2023-01-02 • 云技术社区 • 468 阅读

一. k8s的dashboard搭建

可参考

k8s系列(1)-腾讯云CVM手动部署K8S_Dashboard安装1
k8s系列(1)-腾讯云CVM手动部署K8S_Dashboard安装2
搭建好完成后记住token
kubectl describe secrets -n kube-system $(kubectl -n kube-system get secret | awk '/dashboard-admin/{print $1}')
然后参考界面

image.png

二. 工作负载

我们看腾讯云的集群的类型，新建工作负载可以看到如下类型

类型	含义
StatefulSetPlus	增加版有状态集的运行Pod，支持手动分批升级，自动分批升，原地重启等高级特性
StatefulSet	有状态集的运行Pod
Deployment	可扩展的部署Pod
CronJob	按照Cron的计划定时运行
Job	单次任务
SidecarPlus	边车服务

1. Replica Set

这里与K8S不同的是这里没有SidecarPlus，但是多了Replica Sets，Replication Controllers，Daemon Sets

我们看【k8s中文社区】里面有这么一段话

何时使用ReplicaSet？

ReplicaSet可确保指定数量的pod“replicas”在任何设定的时间运行。然而，Deployments是一个更高层次的概念，它管理ReplicaSets，并提供对pod的声明性更新以及许多其他的功能。因此，我们建议您使用Deployments而不是直接使用ReplicaSets，除非您需要自定义更新编排或根本不需要更新。

2. DaemonSet

如果你需要在所有Node节点统一安装服务，请使用

Daemon Sets是其他地方支持的，这里很奇怪。

我们这里也支持，但是核心原因在咨询了相关同学后得知是

腾讯云的集群都是公共集群，DaemonSet默认会部署到集群所有node，没法做限制
我们对腾讯云集群也有管理权限，平台在腾讯云集群也要部署ds，但是不对公共业务开放

3. StatefulSet(最常用)

3.1 背景

StatefulSet 是用来管理有状态的应用，例如数据库。

前面我们部署的应用，都是不需要存储数据，不需要记住状态的，可以随意扩充副本，每个副本都是一样的，可替代的。

而像数据库、Redis 这类有状态的，则不能随意扩充副本。

StatefulSet 会固定每个 Pod 的名字

3.2 特性

Service 的 CLUSTER-IP 是空的，Pod 名字也是固定的。
Pod 创建和销毁是有序的，创建是顺序的，销毁是逆序的。
Pod 重建不会改变名字，除了IP，所以不要用IP直连

3.3 实战

我们看目录yaml/statefulset

[root@master statefulset]# kubectl get statefulset -o wide
NAME      READY   AGE   CONTAINERS   IMAGES
mongodb   3/3     12m   mongo        mongo:4.4
[root@master statefulset]# kubectl get pods -A
NAMESPACE              NAME                                        READY   STATUS    RESTARTS   AGE
default                mongodb-0                                   1/1     Running   0          12m
default                mongodb-1                                   1/1     Running   0          12m
default                mongodb-2                                   1/1     Running   0          11m

我们通过

kubectl describe  pod mongodb-0 -n default
kubectl describe  pod mongodb-1 -n default

去查看,他们分别被安装在node1和node2节点上

三. 服务

1. Service

官网-服务（Service）

Kubernetes ServiceTypes 允许指定你所需要的 Service 类型，默认是 ClusterIP 。

Type 的取值以及行为如下：

ClusterIP ：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。这也是默认的 ServiceType 。
NodePort：通过每个节点上的 IP 和静态端口（ NodePort ）暴露服务。 NodePort 服务会路由到自动创建的 ClusterIP 服务。通过请求 <节点 IP>:<节点端口> ，你可以从集群的外部访问一个 NodePort 服务。
LoadBalancer：使用云提供商的负载均衡器向外部暴露服务。外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。
ExternalName：通过返回 CNAME 和对应值，可以将服务映射到 externalName 字段的内容（例如， foo.bar.example.com ）。无需创建任何类型代理。

1.2 Headless Services

有时不需要或不想要负载均衡，以及单独的 Service IP。遇到这种情况，可以通过指定 Cluster IP（ spec.clusterIP ）的值为 "None" 来创建 Headless Service。

你可以使用一个无头 Service 与其他服务发现机制进行接口，而不必与 Kubernetes 的实现捆绑在一起。

对于无头 Services 并不会分配 Cluster IP，kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由。 DNS 如何实现自动配置，依赖于 Service 是否定义了选择算符

我们在上述stateful的实战中的例子是把

type: ClusterIP
# HeadLess
clusterIP: None

这里的clusterIP设置为None，

NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kubernetes    ClusterIP   10.96.0.1       <none>        443/TCP          4d1h
mongodb       ClusterIP   None            <none>        27017/TCP        25m
test-k8s-sv   NodePort    10.104.129.21   <none>        8080:31000/TCP   113m

1.3 Service实战

进入yaml/service，

kubectl apply -f app.yaml
kubectl apply -f service.yaml

我们应用之后可以查看service与pod已经进行了绑定，此时可以通过service去调用pod上的服务

[root@master service]# kubectl get pods -o wide
test-k8s-deploy-84c5d4745b-h57xm   1/1     Running   0          2d22h   10.40.0.3   node1   <none>           <none>
test-k8s-deploy-84c5d4745b-rmr54   1/1     Running   0          2d22h   10.38.0.3   node2   <none>           <none>
...
[root@master service]# kubectl get svc
NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kubernetes    ClusterIP   10.96.0.1       <none>        443/TCP          3d23h
test-k8s-sv   NodePort    10.104.129.21   <none>        8080:31000/TCP   3m7s
[root@master service]#  kubectl describe svc test-k8s-sv

在本机上我们来测试，负载均衡结果探测, 发现调用的是不同的pod，成功！

➜  ~ curl http://119.45.4.173:31000/hello/easydoc
hello easydoc
IP lo10.38.0.9, hostname: test-k8s-sv-57b56b6f4d-gqv8h
➜  ~ curl http://119.45.4.173:31000/hello/easydoc
hello easydoc
IP lo10.38.0.7, hostname: test-k8s-sv-57b56b6f4d-hvl6m
➜  ~ curl http://119.45.4.173:31000/hello/easydoc
hello easydoc

2. Ingress

image.png

LoadBalancer的理解(讨论环节)：

需要负载均衡器（通常都需要云服务商提供，裸机可以安装 METALLB 测试）

会额外生成一个 IP 对外服务

K8S 支持的负载均衡器：负载均衡器

比如我有10台机器，1-8机器100%满负荷工作，那么9，10号是10%负荷工作，此时需要LoadBanlancer去把流量调度到9号和10号机器，9号和10号机器去找相关联的service，service去做负载均衡。LoadBalancer做流量入口的负载均衡，service做调度服务的负载均衡

四. 配置

1. configmap

1. 腾讯云的configmap的配置

image.png

1.2 configmap使用

我们进入yaml/configmap/app.yaml看到：

- name: MONGO_ADDRESS
  valueFrom:
    configMapKeyRef:
      name: mongo-config
      key: mongoAddress

2. secret

2.1. TKE的secret的配置

慧用药csig-tom.yaml

image.png

我们去Base64在线解码

data:
  password: MTIzNDU2
  tomxiang: 5ZCR5pmo5a6H

MTIzNDU2->123456

2.2 逻辑上使用

我们进入yaml/configmap看到：

[root@master configmap]# kubectl apply -f ./secret.yaml
[root@master configmap]# kubectl get secret
[root@master configmap]# kubectl get secret mongo-secret -o yaml

我们来看yaml/configmap/mongo.yaml中的使用：

valueFrom:
  secretKeyRef:
    name: mongo-secret
    key: mongo-username

2.3 secret安全性探讨

我们参照关于 K8s 的 Secret 并不安全这件事说的一段话：

当然，社区没有理由意识不到原生 secret 的问题，因此社区也有 Kubernetes Secrets Store CSI Driver ，一种通过 CSI 接口将 Secret 集成到 K8s 的方案。

Secrets Store CSI driver（ secrets-store.csi.k8s.io ）可以让 K8s mount 多个 secret 以 volume 的形式，从外部 KMS mount 到 Pod 里

3. helm

上面都是mongo.yaml的配置，现在我们来看如果不用手写helm的mongodb

安装教程

helm install my-release \\
    --set auth.rootPassword=secretpassword,auth.username=my-user,auth.password=my-password,auth.database=my-database \\
    my-repo/mongodb

五. 存储

image.png

1. 集中存储方式

1. hostpath

把节点上的一个目录挂载到 Pod，但是已经不推荐使用了，文档

配置方式简单，需要手动指定 Pod 跑在某个固定的节点。

仅供单节点测试使用；不适用于多节点集群

这里不推荐就不细讲了

2. 腾讯云上的配置

配置链接慧用药开发环境配置

image.png

3. 裸机配置

[root@node2 data]# cd /root

[root@node2 ~]# ls
Changelog

[root@node2 ~]# mkdir data

[root@master storage]# kubectl apply -f ./sc.yaml 
storageclass.storage.k8s.io/local-storage created

[root@master storage]# kubectl get sc
NAME            PROVISIONER                    RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
cbs (default)   com.tencent.cloud.csi.cbs      Delete          Immediate              false                  6h42m
local-storage   kubernetes.io/no-provisioner   Delete          WaitForFirstConsumer   false                  18s

[root@master storage]# kubectl apply -f ./pv.yaml
persistentvolume/mongodata created

[root@master storage]# kubectl get pv
NAME           CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                   STORAGECLASS    REASON   AGE
mongodata      2Gi        RWO            Delete           Available                           local-storage            9s
mongodata-pv   10Gi       RWO            Retain           Bound       default/mongodata-pvc   cbs                      8h

[root@master storage]# kubectl apply -f ./pvc.yaml
persistentvolumeclaim/mongodata created

[root@master storage]# kubectl get pvc
NAME            STATUS    VOLUME         CAPACITY   ACCESS MODES   STORAGECLASS    AGE
mongodata       Pending                                            local-storage   5s
mongodata-pvc   Bound     mongodata-pv   10Gi       RWO            cbs             8h

[root@master storage]# kubectl delete -f ./mongo.yaml 
statefulset.apps "mongodb" deleted
service "mongodb" deleted

[root@master storage]# kubectl apply -f ./mongo.yaml 
statefulset.apps/mongodb created
service/mongodb created

[root@master storage]# kubectl describe  pod mongodb-0 -n default
展开

我们去node2机器上查看

[root@node2 ~]# cd data
[root@node2 data]# ls
collection-0-3505203164402927752.wt  index-1-3505203164402927752.wt  journal          storage.bson     WiredTiger.turtle
collection-2-3505203164402927752.wt  index-3-3505203164402927752.wt  _mdb_catalog.wt  WiredTiger       WiredTiger.wt
collection-4-3505203164402927752.wt  index-5-3505203164402927752.wt  mongod.lock      WiredTigerHS.wt
diagnostic.data                      index-6-3505203164402927752.wt  sizeStorer.wt    WiredTiger.lock