k8s常用资源-企业实践中手把手教学

K8s在企业中应用广泛，不论是对客户的交付，还是开发人员日常工作中的镜像部署等操作，都离不开K8s，现在通过Yaml文件统一地实现一套开发部署流程，从而介绍K8s

K8s中的资源类型(一下内容均为自己使用时的感悟，欢迎交流)

• 工作负载中常用资源对象：POD，ReplicaSet，Job，Deployment，StatefulSet，DaemonSet，ReplicaSet …

工作负载中的资源对象是K8s的基础资源，我们所做的项目都需要部署到这些具体的资源中，其中pod是k8s的最小单位，项目就需要挂到pod下的容器中，有了pod才能启动后续的操作。而比如deployment和job则是pod的管理单位，就好像班级的班主任一样，他会管理他下面的学生(pod),二者区别在于，deployment下的pod在碰到error死亡后，会重新拉取镜像再次部署pod，而job下的pod死亡后便会直接删除pod，根据二者的区别也能发现，一般开发中的前后端项目是要放在deployment下的pod中，项目崩溃后再次重新拉取镜像，再次部署上去，否则使用job的话碰到bug整个项目就会直接删除掉

• 服务及负载均衡：Service，Ingress…

服务和负载均衡统一使用在将k8s中需要对外使用的项目对外暴漏，其会为项目提供一个ip和域，通过ip域就可以调用自己部署的服务

• 常用资源：ConfigMap,Volume,CSI…

常用的资源就是在本k8s中绝大多数的项目都要使用到的资源，并且该资源具有通用性，比如企业中的k8s都有自己的config文件用于识别，此时不能在每个项目都单独添加config内容，不可能也不显示，更合理的方案则是将config内容声明到configMap中，需要用到config文件内容的直接将configMap挂载到pod中读取（使用volumes属性）

• 集群资源: Namespace，Node，Role…

对集群资源的理解，可以将其理解成一个学校中的不同的班级，班级的作用是把每个学生分割开，每个班级都有自己的教室，学生在教室中从事自己的学业，而集群资源就起到了逻辑存储，逻辑分割的作用

k8s一套资源创建流程实例

1. 创建namespace实例

apiVersion: v1
kind: Namespace
metadata:
  name: test

其中kind必须为Namespace，metadata中声明namespace的name即可

2. 创建configMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-config
  namespace: test #上面定义的namespace
data:
  config.yml: |
    apiVersion: v1
    kind: Config
    clusters:
    - cluster:
        api-version: v1
        certificate-authority-data: 这里是一长串字符内容
        server: "https://xxxx:yyyy"
      name: "yanshi"
    contexts:
    - context:
          cluster: "yanshi"
          user: "kube-admin-yanshi"
      name: "yanshi"
    current-context: "yanshi"
    users:
    - name: "kube-admin-yanshi"
      user:
        client-certificate-data: 这里是一长串字符内容
        client-key-data: 这里是一长串字符内容

以上即可创建一个configMap，里面内容实例为一个k8s平台的config内容，具体根据不同平台而定
configMap的内容可以挂载到pod中使用，挂载后会在pod容器的config中生成config.yml文件(在configMap定义的data属性下，第一行内容为挂在后的文件起名，比如本例就起名为config.yml)
在容器中使用config.yml文件通过linux命令或代码调用即可

3. 创建一个deployment，下面挂载一个pod

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
  namespace: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
        deployment: test-deployment
    spec:

      containers:
        - name: excute-node
          image: xxxx:yyyy/image
          # 镜像
          ports:
            - name: http
              containerPort: 8082
              protocol: TCP
          resources:
            limits:
              cpu: '2'
              memory: 4Gi
            requests:
              cpu: '1'
              memory: 1Gi
          imagePullPolicy: Always
          volumeMounts:#声明将configMap中的config.yml文件挂载到/etc/config目录下
            - mountPath: /etc/config
              name: config-volume #和pod的volumes下的name对应
          env: #容器的环境变量，定义一些常用变量
           

      restartPolicy: Always
      volumes:#在pod中挂载configMap
        - name: config-volume
          configMap:
            name: test-config

如上所示创建一个deployment实例,deployment中实现了一个pod，在pod中挂载了configMap，同时包含一个容器
pod下的image属性为自己的镜像路径，根据自己镜像路径修改，比如自己的后端服务
pod的volumes和pod下容器的volumeMounts分别用于挂载configMap和声明把configMap的内容挂载到容器中的某个文件夹下，容器通过volumes中的name和pod挂载的configMap通信，如下所示成功挂在了config.yml文件
deployment的app属性很核心，其用于让service通过selector识别deployment

4. 创建service暴漏pod

apiVersion: v1
kind: Service
metadata:
  name: excute-node-service
  namespace: test
spec:
  selector:
    app: test #和deployment的app属性对应
  ports:
    - protocol: TCP
      port: 8082         # 服务暴露的端口
      targetPort: 8082 #Pod 内部应用程序的端口

  type: NodePort   # 或者使用 NodePort，视具体情况而定

此时便可以外部访问我们的服务，如下所示

查看自己的service对外暴漏的端口和ip通过点击进入service查看，如下所示即为ip

端口则是service的对外节点，如下所示

此时，一套创建流程就走完了，欢迎一起学习