常见的kind类型

1、Endpoints

Endpoints可以把外部的链接到k8s系统中（可以理解为引用外部资源，如将一个外部mysql连接到k8s中）

2、Service

部署一个内部虚拟IP，其他deployment可以链接。（可以简单理解为K8S的端口映射，如外部3444端口映射到pod应用中80端口）

3、Secrets

用于存储和管理一些敏感数据，比如密码，token，密钥等敏感信息。（可以理解为ssh中的密钥）

4、Deployment

部署一个Pod，内部只能链接service，无法互相链接。（可以简单理解为一个pod应用的部署工具，即使部署的应用挂了还能自动重启Pod，但只能链接service服务）

下面分别对下面几种kind类型来进行讲解：

一、Endpoints

先来看个需求：
我有个一个外部的 mysql，不是使用本机的k8s部署的。但是现在我的应用程序想用它。那这时候，我改怎么使用它呢？毕竟k8s中的pod大部分只能通过service来链接。
这时候Endpoints就出现了，他是可以把外部的链接到k8s系统中，如：

apiVersion: v1
kind: Endpoints
metadata:
  name: suncat-endpoints
subsets:
  - addresses: # 代理ip
      - ip: 192.168.14.144
    ports:
      - port: 3306 # 服务的端口
        protocol: TCP
        name: http
 
---
apiVersion: v1
kind: Service
metadata:
  name: suncat-endpoints # 这里的名称要和上面一样才能关联
spec:
  ports:
    - port: 3306
      targetPort: 3306
      protocol: TCP
      name: http

（1）首先我们看到，我们定义了名为suncat-endpoints的Endpoints，同时往suncat-endpoints配置了代理IP以及服务的端口。
（2）接着我们看下一个，以---分隔符隔开的另一个类型Service，定义了一个名为suncat-endpoints的Service，同时往该Service中配置内部端口映射到Pod暴露出的端口port: 3306，以及对外暴露的端口号targetPort: 3306

总结：通过配置Endpoints以及Service，Endpoints将k8s的端口链接到外部mysql端口，而Service将k8s中内部的端口映射到k8s端口，以此就完成了pod应用访问外部链接。

二、Service

先来看个需求：
我们K8S里启动了一个pod应用，并里面运行了端口为8848的前端页面。这时候，我外部怎么访问K8S内部pod应用这个端口为8848的前端页面？
这时候就需要定义Service类型了，使pod应用端口8848映射到K8S特定端口中，外部应用访问K8S特定端口即可访问前端页面

apiVersion: v1
kind: Service
metadata:
  name: suncat-service
spec:
  type: NodePort
  ports:
# 内部端口映射到Pod暴露出的端口
  - port: 8848
# 对外暴露的端口号，如果不指定则随机生成一个端口号
    nodePort: 38011
  selector:
    app: suncat-app

首先我们看到，定义了一个名为suncat-service的Service类型，他的职责时将port: 8848端口映射到nodePort: 38011对外暴露端口，并且他的管理的对应的应用时suncat-app应用
也就是说，将pod应用名为suncat-app中端口为8848的端口映射到对外暴露端口38011，只要外部服务访问该服务器IP:38011,即可区访问k8s中suncat-app应用的8848端口

三、Secrets

这个类型比较有意思，更多是用作于类似密钥的形式。
（估计是不想明文记录账号密码等信息，但大部分加密都是Base64加密。所以说，我觉得有点像是防君子不防小人）

Secret有三种类型:
（1）Opaque：base64 编码格式的 Secret，用来存储密码、密钥等；但数据也可以通过base64 –decode解码得到原始数据，所有加密性很弱。
（2）Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的的/run/secrets/kubernetes.io/serviceaccount 目录中。
（3）kubernetes.io/dockerconfigjson ：用来存储私有docker registry的认证信息。

四、Deployment

先来看一下需求：
我们希望在k8s上部署一个应用，如果该应用挂了还能重启。如果单单创建一个pod类型是不够的，应为该pod应用挂了，就不会重启了。
如果创建一个Deployment类型，可以创建管理该pod应用，挂了都会给你重启。

例子：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: suncat-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: suncat-app
  template:
    metadata:
      labels:
        app: suncat-app
    spec:
      imagePullSecrets:
      - name: suncat-harbor-secret
      containers:
      - name: suncat-app
        image: registry.k8s.suncat:4444/suncat/testapp:1.0
        ports:
          - containerPort: 8848
        imagePullPolicy: Always
        resources:
          limits:
            cpu: "1"
            memory: "400Mi"
          requests:
            cpu: "0.5"
            memory: "200Mi"

以上内容有点多，我们慢慢讲解：

（1）首先，我们定义了名为suncat-deployment的Deployment，并且该Deployment所管理的app应用的标签是suncat-app，副本数为1。
（2）然后在数据定义里定义了一个定义业务模板template。可以看出，在业务模板里定义了一个名为suncat-app的pod应用。
（3）同时该业务模板还定义了该suncat-app应用的容器名，同样也名为suncat-app，而该容器所拉取的镜像来源于registry.k8s.suncat:4444/suncat/testapp:1.0。这时候就会有人问，如果该拉取镜像的地址是非公开的，需要密码的。那该怎么办呢？
。还记得上面说到的类型Secrets下的kubernetes.io/dockerconfigjson种类么，这东西就是用来作密钥拉镜像的，只需要在imagePullSecrets下配置一个事先创建好的、名为suncat-harbor-secret 的密钥即可拉取镜像
（4）就是配置一些该pod的端口为8848，拉取方式imagePullPolicy为Always总是拉取pull
（5）这个的话，就是配置该pod的正常请求cpu和内存，以及最大限制的cpu和内存。当然你不设置也所谓。在该配置中，我设置该pod正常请求的cpu为0.5（半核）以及内存为200M，最大限制的cpu为1核、以及内存为400M

备注：

1、imagePullPolicy拉取方式参数详情有哪些？

Always：总是拉取pull
IfNotPresent：默认值,本地有则使⽤本地镜像,不拉取
Never：只使⽤本地镜像，从不拉取

原文链接：
https://blog.csdn.net/github_37130188/article/details/126199473

标签：kind,Service,Kubernetes,app,端口,suncat,yaml,pod,k8s
From： https://www.cnblogs.com/eddyz/p/17218595.html

k8s(Kubernetes)中yaml文件的各种 kind 类型