Kubernetes-note

原创 已于 2023-04-09 20:48:36 修改 · 340 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#kubernetes

于 2023-04-07 11:32:51 首次发布

Master节点和Node节点概念

Master节点

Master节点是Kubernetes集群的控制节点，在生产环境中不建议部署集群核心组件外的任何Pod，公司业务的Pod更是不建议部署到Master节点上，以免升级或者维护时对业务造成影响。

Master节点的组件包括：

APIServer：APIServer是整个集群的控制中枢，提供集群中各个模块之间的数据交换，并将集群状态和信息存储到分布式键-值(key-value)存储系统Etcd集群中。同时它也是集群管理、资源配额、提供完备的集群安全机制的入口，为集群各类资源对象提供增删改查以及watch的REST API接口。APIServer作为Kubernetes的关键组件，使用Kubernetes API和 JSON over HTTP提供Kubernetes的内部和外部接口。

Scheduler：Scheduler是集群Pod的调度中心，主要是通过调度算法将Pod分配到最佳的节点（Node），它通过APIServer监听所有Pod的状态，一旦发现新的未被调度到任何Node节点的Pod（PodSpec.NodeName为空），就会根据一系列策略选择最佳节点进行调度，对每一个Pod创建一个绑定（binding），然后被调度的节点上的Kubelet负责启动该Pod。Scheduler是集群可插拔式组件，它跟踪每个节点上的资源利用率以确保工作负载不会超过可用资源。因此Scheduler必须知道资源需求、资源可用性以及其他约束和策略，例如服务质量、亲和力/反关联性要求、数据位置等。Scheduler将资源供应与工作负载需求相匹配以维持系统的稳定和可靠，因此Scheduler在调度的过程中需要考虑公平、资源高效利用、效率等方面的问题。

Controller Manager： Controller Manager是集群状态管理器（它的英文直译名为控制器管理器），以保证Pod或其他资源达到期望值。当集群中某个Pod的副本数或其他资源因故障和错误导致无法正常运行，没有达到设定的值时，Controller Manager会尝试自动修复并使其达到期望状态。Controller Manager包含NodeController、ReplicationController、EndpointController、NamespaceController、ServiceAccountController、ResourceQuotaController、ServiceController和TokenController，该控制器管理器可与API服务器进行通信以在需要时创建、更新或删除它所管理的资源，如Pod、服务断点等。

Etcd： Etcd由CoreOS开发，用于可靠地存储集群的配置数据，是一种持久性、轻量型、分布式的键-值（key-value）数据存储组件。Etcd作为Kubernetes集群的持久化存储系统，集群的灾难恢复、状态信息存储都与其密不可分，所以在Kubernetes高可用集群中，Etcd的高可用是至关重要的一部分，在生产环境中建议部署为大于3的奇数个数的Etcd，以保证数据的安全性和可恢复性。Etcd可与Master组件部署在同一个节点上，大规模集群环境下建议部署在集群外，并且使用高性能服务器来提高Etcd的性能和降低Etcd同步数据的延迟。

Node节点

Node节点也被称为Worker或Minion，是主要负责部署容器（工作负载）的单机（或虚拟机），集群中的每个节点都必须具备容器的运行环境（runtime），比如Docker及其他组件等。
Kubelet作为守护进程运行在Node节点上，负责监听该节点上所有的Pod，同时负责上报该节点上所有Pod的运行状态，确保节点上的所有容器都能正常运行。当Node节点宕机（NotReady状态）时，该节点上运行的Pod会被自动地转移到其他节点上。

Node节点包括：
Kubelet： 负责与Master通信协作，管理该节点上的Pod。

Kube-Proxy： 负责各Pod之间的通信和负载均衡。

Docker Engine： Docker引擎，负载对容器的管理。

Pod概念

什么是Pod？

Pod可简单地理解为是一组、一个或多个容器，具有共享存储/网络及如何运行容器的规范。Pad包含一个或多个相对紧密耦合的应用程序容器，处于同一个Pod中的容器共享同样的存储空间（Volume，卷或存储卷）、IP地址和Port端口，容器之间使用localhost:port相互访问。根据Docker的构造，Pod可被建模为一组具有共享命令空间、卷、IP地址和Port端口的Docker容器。
Pod包含的容器最好是一个容器只运行一个进程。每个Pod包含一个pause容器，pause容器是Pod的父容器，它主要负责僵尸进程的回收管理。
Kubernetes为每个Pod都分配一个唯一的IP地址，这样就可以保证应用程序使用同一端口，避免了发生冲突的问题。

Pod字段解析
apiVersion: v1 # 必选，API的版本号
kind: Pod	# 必选，类型Pod
metadata:	# 必选，元数据
  name: nginx	# 必选，符合RFC 1035规范的Pod名称
  namespace: web-testing # 可选，不指定默认为default，Pod所在的命名空间
  labels:	# 可选，标签选择器，一般用于Selector
    - app: nginx
  annotations:	# 可选，注释列表
    - app: nginx
spec:	# 必选，用于定义容器的详细信息
  containers:	# 必选，容器列表
  - name: nginx	# 必选，符合RFC 1035规范的容器名称
    image: nginx: v1	# 必选，容器所用的镜像的地址
    imagePullPolicy: Always	# 可选，镜像拉取策略
	command: 
	- nginx	# 可选，容器启动执行的命令
	- -g
	- "daemon off;"
		workingDir: /usr/share/nginx/html	# 可选，容器的工作目录
		volumeMounts:	# 可选，存储卷配置
		- name: webroot # 存储卷名称
		  mountPath: /usr/share/nginx/html # 挂载目录
		  readOnly: true	# 只读
		ports:	# 可选，容器需要暴露的端口号列表
		- name: http	# 端口名称
		  containerPort: 80	# 端口号
		  protocol: TCP	# 端口协议，默认TCP
		env:	# 可选，环境变量配置
		- name: TZ	# 变量名
		  value: Asia/Shanghai
		- name: LANG
		  value: en_US.utf8
		resources:	# 可选，资源限制和资源请求限制
		  limits:	# 最大限制设置
			cpu: 1000m
			memory: 1024MiB
		  requests:	# 启动所需的资源
			cpu: 100m
			memory: 512MiB
		readinessProbe:	# 可选，容器状态检查
		httpGet:	# 检测方式
			path: /	# 检查路径
			port: 80	# 监控端口
		  timeoutSeconds: 2	# 超时时间 
		  initialDelaySeconds: 60	# 初始化时间
		livenessProbe:	# 可选，监控状态检查
		  exec:	# 检测方式
			command: 
			- cat
			- /health
		  httpGet:	# 检测方式
			path: /_health
			port: 8080
			httpHeaders:
			- name: end-user
			  value: jason
		  tcpSocket:	# 检测方式
			port: 80
		  initialDelaySeconds: 60	# 初始化时间
		  timeoutSeconds: 2	# 超时时间
		  periodSeconds: 5	# 检测间隔
		  successThreshold: 2 # 检查成功为2次表示就绪
		  failureThreshold: 1 # 检测失败1次表示未就绪
		securityContext:	# 可选，限制容器不可信的行为
		  provoleged: false
	  restartPolicy: Always	# 可选，默认为Always
	  nodeSelector:	# 可选，指定Node节点
		region: subnet7
	  imagePullSecrets:	# 可选，拉取镜像使用的secret
	  - name: default-dockercfg-86258
	  hostNetwork: false	# 可选，是否为主机模式，如是，会占用主机端口
	  volumes:	# 共享存储卷列表
	  - name: webroot # 名称，与上述对应
		emptyDir: {}	# 共享卷类型，空
		hostPath:		# 共享卷类型，本机目录
		  path: /etc/hosts
		secret:	# 共享卷类型，secret模式，一般用于密码
		  secretName: default-token-tf2jp # 名称
		  defaultMode: 420 # 权限
		  configMap:	# 一般用于配置文件
		  name: nginx-conf
		  defaultMode: 420

Deployment

虽然ReplicaSet可以确保在任何给定时间运行的Pod副本达到指定的数量，但是Deployment（部署）是一个更高级的概念，它管理ReplicaSet并为Pod和ReplicaSet提供声明性更新以及许多其他有用的功能，所以建议在实际使用中，使用Deployment代替ReplicaSet。

如果在Deployment对象中描述了所需的状态，Deployment控制器就会以可控制的速率将实际状态更改为期望状态。也可以在Deployment中创建新的ReplicaSet，或者删除现有的Deployment并使用新的Deployment部署所用的资源。

用于部署无状态的服务，这个最常用的控制器。一般用于管理维护企业内部无状态的微服务，比如configserver、zuul、springboot。他可以管理多个副本的Pod实现无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。

创建Deployment

创建一个Deployment文件，并命名为dc-nginx.yaml，用于部署三个Nginx Pod：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

示例解析：

  • nginx-deployment：Deployment的名称。

  • replicas： 创建Pod的副本数。

  • selector：定义Deployment如何找到要管理的Pod，与template的label（标签）对应。

  • template字段包含以下字段：

    • app: nginx使用label（标签）标记Pod
    • spec：表示Pod运行一个名字为nginx的容器。
    • image：运行此Pod使用的镜像
    • Port：容器用于发送和接收流量的端口

使用kubectl create创建此Deployment：

[root@k8s-master01 2.2.8.1]# kubectl create -f dc-nginx.yaml 
deployment.apps/nginx-deployment created

使用kubectl get或者kubectl describe查看此Deployment：

[root@k8s-master01 2.2.8.1]# kubectl get deploy
NAME        DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
nginx-deployment  3     3     3      1      60s

其中：

  • NAME：集群中Deployment的名称。

  • DESIRED：应用程序副本数。

  • CURRENT：当前正在运行的副本数。

  • UP-TO-DATE：显示已达到期望状态的被更新的副本数。

  • AVAILABLE：显示用户可以使用的应用程序副本数，当前为1，因为部分Pod仍在创建过程中。

  • AGE：显示应用程序运行的时间。

查看此时Deployment rollout的状态：

[root@k8s-master01 2.2.8.1]# kubectl rollout status deployment/nginx-deployment
deployment "nginx-deployment" successfully rolled out

再次查看此Deployment：

[root@k8s-master01 2.2.8.1]# kubectl get deploy
NAME        DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
nginx-deployment  3     3     3      3      11m

查看此Deployment创建的ReplicaSet：

[root@k8s-master01 2.2.8.1]# kubectl get rs
NAME             DESIRED  CURRENT  READY  AGE
nginx-deployment-5c689d88bb  3     3     3    12m

查看此Deployment创建的Pod：

[root@k8s-master01 2.2.8.1]# kubectl get pods --show-labels
NAME                READY  STATUS  RESTARTS  AGE  LABELS
nginx-deployment-5c689d88bb-6b95k  1/1   Running  0     13m  app=nginx,pod-template-hash=5c689d88bb
nginx-deployment-5c689d88bb-9z5z2  1/1   Running  0     13m  app=nginx,pod-template-hash=5c689d88bb
nginx-deployment-5c689d88bb-jc8hr  1/1   Running  0     13m  app=nginx,pod-template-hash=5c689d88bb
更新Deployment

一般对应用程序升级或者版本迭代时，会通过Deployment对Pod进行滚动更新。

假如更新Nginx Pod的image使用nginx:1.9.1：

[root@k8s-master01 2.2.8.1]# kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record
deployment.extensions/nginx-deployment image updated

当然也可以直接编辑Deployment，效果相同：

[root@k8s-master01 2.2.8.1]#  kubectl edit deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment edited

使用kubectl rollout status查看更新状态：

[root@k8s-master01 2.2.8.1]# kubectl rollout status deployment.v1.apps/nginx-deployment
Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "nginx-deployment" successfully rolled out

查看ReplicaSet：

[root@k8s-master01 2.2.8.1]# kubectl get rs 
NAME             DESIRED  CURRENT  READY  AGE
nginx-deployment-5c689d88bb  0     0     0    34m
nginx-deployment-6987cdb55b  3     3     3    5m14s

通过describe查看Deployment的详细信息：

[root@k8s-master01 2.2.8.1]# kubectl describe deploy nginx-deployment
Name:          nginx-deployment
Namespace:       default
CreationTimestamp:   Thu, 24 Jan 2019 15:15:15 +0800
Labels:         app=nginx
Annotations:      deployment.kubernetes.io/revision: 2
​            kubernetes.io/change-cause: kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
Selector:        app=nginx
Replicas:        3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:      RollingUpdate
MinReadySeconds:    0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
 Labels: app=nginx
 Containers:
  nginx:
  Image:    nginx:1.9.1
  Port:     80/TCP
  Host Port:  0/TCP
  Environment: <none>
  Mounts:    <none>
 Volumes:    <none>
Conditions:
 Type      Status Reason
 ----      ------ ------
 Available   True  MinimumReplicasAvailable
 Progressing  True  NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet:  nginx-deployment-6987cdb55b (3/3 replicas created)
Events:
 Type  Reason       Age  From          Message
 ----  ------       ----  ----          -------
 Normal ScalingReplicaSet 36m  deployment-controller Scaled up replica set nginx-deployment-5c689d88bb to 3
 Normal ScalingReplicaSet 7m16s deployment-controller Scaled up replica set nginx-deployment-6987cdb55b to 1
 Normal ScalingReplicaSet 5m18s deployment-controller Scaled down replica set nginx-deployment-5c689d88bb to 2
 Normal ScalingReplicaSet 5m18s deployment-controller Scaled up replica set nginx-deployment-6987cdb55b to 2
 Normal ScalingReplicaSet 4m35s deployment-controller Scaled down replica set nginx-deployment-5c689d88bb to 
 Normal ScalingReplicaSet 4m34s deployment-controller Scaled up replica set nginx-deployment-6987cdb55b to 3
 Normal  ScalingReplicaSet  3m30s  deployment-controller  Scaled down replica set nginx-deployment-5c689d88bb to 0

在describe中可以看出，第一次创建时，它创建了一个名为nginx-deployment-5c689d88bb的ReplicaSet，并直接将其扩展为3个副本。更新部署时，它创建了一个新的ReplicaSet，命名为nginx-deployment-6987cdb55b，并将其副本数扩展为1，然后将旧的ReplicaSet缩小为2，这样至少可以有2个Pod可用，最多创建了4个Pod。以此类推，使用相同的滚动更新策略向上和向下扩展新旧ReplicaSet，最终新的ReplicaSet可以拥有3个副本，并将旧的ReplicaSet缩小为0。

回滚Deployment

当新版本不稳定时，可以对其进行回滚操作，默认情况下，所有Deployment的rollout历史都保留在系统中，可以随时回滚。

假设我们又进行了几次更新：

[root@k8s-master01 2.2.8.1]# kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v1 --record

[root@k8s-master01 2.2.8.1]# kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record

使用kubectl rollout history查看部署历史：

[root@k8s-master01 2.2.8.1]# kubectl rollout history deployment/nginx-deployment
deployment.extensions/nginx-deployment
REVISION CHANGE-CAUSE
1     <none>
2     kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
3     kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v1 --record=true
4     kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record=true

查看Deployment某次更新的详细信息，使用–revision指定版本号：

[root@k8s-master01 2.2.8.1]# kubectl rollout history deployment.v1.apps/nginx-deployment --revision=3
deployment.apps/nginx-deployment with revision #3
Pod Template:
 Labels:  app=nginx
  pod-template-hash=645959bf6b
 Annotations: kubernetes.io/change-cause: kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v1 --record=true
 Containers:
  nginx:
  Image: dotbalo/canary:v1
  Port:  80/TCP
  Host Port: 0/TCP
  Environment: <none>
  Mounts: <none>
 Volumes: <none>

使用kubectl rollout undo回滚到上一个版本：

[root@k8s-master01 2.2.8.1]# kubectl rollout undo deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment

再次查看更新历史，发现REVISION5回到了canary:v1：

[root@k8s-master01 2.2.8.1]# kubectl rollout history deployment/nginx-deployment
deployment.extensions/nginx-deployment
REVISION CHANGE-CAUSE
1     <none>
2     kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
4     kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record=true
5     kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v1 --record=true

使用–to-revision参数回到指定版本：

[root@k8s-master01 2.2.8.1]# kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment.extensions/nginx-deployment
扩展Deployment

当公司访问量变大，三个Pod已无法支撑业务时，可以对其进行扩展。

使用kubectl scale动态调整Pod的副本数，比如增加Pod为5个：

[root@k8s-master01 2.2.8.1]# kubectl scale deployment.v1.apps/nginx-deployment --replicas=5
deployment.apps/nginx-deployment scaled

查看Pod，此时Pod已经变成了5个：

[root@k8s-master01 2.2.8.1]# kubectl get po
NAME                READY  STATUS  RESTARTS  AGE
nginx-deployment-5f89547d9c-5r56b  1/1   Running  0     90s
nginx-deployment-5f89547d9c-htmn7  1/1   Running  0     25s
nginx-deployment-5f89547d9c-nwxs2  1/1   Running  0     99s
nginx-deployment-5f89547d9c-rpwlg  1/1   Running  0     25s
nginx-deployment-5f89547d9c-vlr5p  1/1   Running  0     95s
暂停和恢复Deployment更新

Deployment支持暂停更新，用于对Deployment进行多次修改操作。

使用kubectl rollout pause暂停Deployment更新：

[root@k8s-master01 2.2.8.1]# kubectl rollout pause deployment/nginx-deployment
deployment.extensions/nginx-deployment paused

然后对Deployment进行相关更新操作，比如更新镜像，然后对其资源进行限制：

[root@k8s-master01 2.2.8.1]# kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
deployment.apps/nginx-deployment image updated

[root@k8s-master01 2.2.8.1]# kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
deployment.apps/nginx-deployment resource requirements updated

通过rollout history可以看到没有新的更新：

[root@k8s-master01 2.2.8.1]# kubectl rollout history deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment
REVISION CHANGE-CAUSE
1     <none>
5     kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v1 --record=true
7     kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record=true
8     kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record=true

使用kubectl rollout resume恢复Deployment更新：

[root@k8s-master01 2.2.8.1]# kubectl rollout resume deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment resumed

可以查看到恢复更新的Deployment创建了一个新的RS（复制集）：

[root@k8s-master01 2.2.8.1]# kubectl get rs
NAME             DESIRED  CURRENT  READY  AGE
nginx-deployment-57895845b8  5     5     4    11s

可以查看Deployment的image（镜像）已经变为nginx:1.9.1

[root@k8s-master01 2.2.8.1]# kubectl describe deploy nginx-deployment
Name:          nginx-deployment
Namespace:       default
CreationTimestamp:   Thu, 24 Jan 2019 15:15:15 +0800
Labels:         app=nginx
Annotations:      deployment.kubernetes.io/revision: 9
​            kubernetes.io/change-cause: kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record=true
Selector:        app=nginx
Replicas:        5 desired | 5 updated | 5 total | 5 available | 0 unavailable
StrategyType:      RollingUpdate
MinReadySeconds:    0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
 Labels: app=nginx
 Containers:
  nginx:
  Image:   nginx:1.9.1
  Port:    80/TCP
  Host Port: 0/TCP
更新Deployment的注意事项
# kubectl get deploy nginx -oyaml
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "12"
    kubernetes.io/change-cause: kubectl set image deploy nginx nginx=nginx:1.15.3
      --record=true
  creationTimestamp: "2020-09-19T02:41:11Z"
  generation: 19
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  progressDeadlineSeconds: 600
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.15.3
        imagePullPolicy: IfNotPresent
        name: nginx
        resources:
          limits:
            cpu: 200m
            memory: 128Mi
          requests:
            cpu: 10m
            memory: 16Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

清理策略：

在默认情况下，revision保留10个旧的ReplicaSet，其余的将在后台进行垃圾回收，可以在.spec.revisionHistoryLimit设置保留ReplicaSet的个数。当设置为0时，不保留历史记录。

滚动更新策略：

  • .spec.strategy.type==Recreate，表示重建，先删掉旧的Pod再创建新的Pod。

  • .spec.strategy.type==RollingUpdate，表示滚动更新，可以指定 maxUnavailable 和 maxSurge 来控制滚动更新过程。

  • .spec.strategy.rollingUpdate.maxUnavailable，指定在回滚更新时最大不可用的Pod数量，可选字段，默认为25%，可以设置为数字或百分比，如果 maxSurge 为0，则该值不能为0。

  • .spec.strategy.rollingUpdate.maxSurge可以超过期望值的最大Pod数，可选字段，默认为25%，可以设置成数字或百分比，如果 maxUnavailable 为0，则该值不能为0。

StatefulSet

StatefulSet（有状态集）常用于部署有状态的且需要有序启动的应用程序。

StatefulSet（有状态集，缩写为 sts ）常用于部署有状态的且需要有序启动的应用程序，比如在进行 SpringCloud 项目容器化时，Eureka的部署是比较适合用 StatefulSet 部署方式的，可以给每个Eureka实例创建一个唯一且固定的标识符，并且每个Eureka 实例无需配置多余的 Service ，其余 Spring Boot 应用可以直接通过Eureka的Headless Service即可进行注册。

Eureka的statefulset的资源名称是eureka，eureka-0 eureka-1 eureka-2

Service：headless service，没有ClusterIP eureka-svc

Eureka-0.eureka-svc.NAMESPACE_NAME eureka-1.eureka-svc …

StatefulSet的基本概念

StatefulSet主要用于管理有状态应用程序的工作负载API对象。比如在生产环境中，可以部署ElasticSearch集群、MongoDB集群或者需要持久化的RabbitMQ集群、Redis集群、Kafka集群和ZooKeeper集群等。

和Deployment类似，一个StatefulSet也同样管理着基于相同容器规范的Pod。不同的是，StatefulSet为每个Pod维护了一个粘性标识。这些Pod是根据相同的规范创建的，但是不可互换，每个Pod都有一个持久的标识符，在重新调度时也会保留，一般格式为StatefulSetName-Number。比如定义一个名字是Redis-Sentinel的StatefulSet，指定创建三个Pod，那么创建出来的Pod名字就为Redis-Sentinel-0、Redis-Sentinel-1、Redis-Sentinel-2。而StatefulSet创建的Pod一般使用Headless Service（无头服务）进行通信，和普通的Service的区别在于Headless Service没有ClusterIP，它使用的是Endpoint进行互相通信，Headless一般的格式为

statefulSetName-{0…N-1}.serviceName.namespace.svc.cluster. local。

说明：

  • serviceName为Headless Service的名字。

  • 0..N-1为Pod所在的序号，从0开始到N-1。

  • statefulSetName为StatefulSet的名字。

  • namespace为服务所在的命名空间。

  • .cluster.local为Cluster Domain（集群域）。

比如用一个名为redis-ms的StatefulSet部署主从架构的Redis，第一个容器启动时，它的标识符为redis-ms-0，并且Pod内主机名也为redis-ms-0，此时就可以根据主机名来判断，当主机名为redis-ms-0的容器作为Redis的主节点，其余从节点，那么Slave连接Master主机配置就可以使用不会更改的Master的Headless Service，此时Redis从节点（Slave）配置文件如下：

port 6379
slaveof redis-ms-0.redis-ms.public-service.svc.cluster.local 6379
tcp-backlog 511
timeout 0
tcp-keepalive 0
……

其中redis-ms-0.redis-ms.public-service.svc.cluster.local是Redis Master的Headless Service，在同一命名空间下只需要写redis-ms-0.redis-ms即可，后面的public-service.svc.cluster.local可以省略。

StatefulSet注意事项

一般StatefulSet用于有以下一个或者多个需求的应用程序：

  • 需要稳定的独一无二的网络标识符。

  • 需要持久化数据。

  • 需要有序的、优雅的部署和扩展。

  • 需要有序的自动滚动更新。

如果应用程序不需要任何稳定的标识符或者有序的部署、删除或者扩展，应该使用无状态的控制器部署应用程序，比如Deployment或者ReplicaSet。

StatefulSet 是Kubernetes 1.9版本之前的beta资源，在1.5版本之前的任何Kubernetes版本都没有。

Pod 所用的存储必须由 PersistentVolume Provisioner（持久化卷配置器）根据请求配置 StorageClass，或者由管理员预先配置，当然也可以不配置存储。

为了确保数据安全，删除和缩放 StatefulSet 不会删除与StatefulSet 关联的卷，可以手动选择性地删除PVC和PV

StatefulSet目前使用Headless Service（无头服务）负责 Pod 的网络身份和通信，需要提前创建此服务。

删除一个 StatefulSet 时，不保证对Pod的终止，要在 StatefulSet 中实现Pod的有序和正常终止，可以在删除之前将StatefulSet的副本缩减为0。

定义一个StatefulSet资源文件

定义一个简单的StatefulSet的示例如下：

apiVersion: v1
kind: Service
metadata:
 name: nginx
 labels:
  app: nginx
spec:
 ports:
 - port: 80
  name: web
 clusterIP: None
 selector:
  app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: web
spec:
 serviceName: "nginx"
 replicas: 2
 template:
  metadata:
   labels:
     app: nginx
  spec:
   containers:
   - name: nginx
     image: nginx
     ports:
     - containerPort: 80
       name: web

其中，

  • kind: Service定义了一个名字为Nginx的Headless Service，创建的Service格式为nginx-0.nginx.default.svc.cluster.local，其他的类似，因为没有指定Namespace（命名空间），所以默认部署在default。
  • kind: StatefulSet定义了一个名字为web的StatefulSet，replicas表示部署Pod的副本数，本实例为2。

在StatefulSet中必须设置Pod选择器（.spec.selector）用来匹配其标签（.spec.template.metadata.labels）。在1.8版本之前，如果未配置该字段（.spec.selector），将被设置为默认值，在1.8版本之后，如果未指定匹配Pod Selector，则会导致StatefulSet创建错误。

当StatefulSet控制器创建Pod时，它会添加一个标签statefulset.kubernetes.io/pod-name，该标签的值为Pod的名称，用于匹配Service。

创建StatefulSet

创建StatefulSet：

[root@k8s-master01 ~]# # 创建一个sts
[root@k8s-master01 ~]# kubectl create -f nginx-sts.yaml # -n namespace_name
service/nginx created
statefulset.apps/web created
[root@k8s-master01 ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   14d
nginx        ClusterIP   None         <none>        80/TCP    <invalid>
[root@k8s-master01 ~]# kubectl get po 
NAME    READY   STATUS    RESTARTS   AGE
web-0   1/1     Running   0          24s
web-1   1/1     Running   0          19s
[root@k8s-master01 ~]# # 更改副本数为3
[root@k8s-master01 ~]# kubectl scale --replicas=3 sts web 
[root@k8s-master01 ~]# # 查看Pod
[root@k8s-master01 ~]# 
[root@k8s-master01 ~]# kubectl get po
NAME    READY   STATUS              RESTARTS   AGE
web-0   1/1     Running             0          58s
web-1   1/1     Running             0          53s
web-2   0/1     ContainerCreating   0          13s
[root@k8s-master01 ~]# # 解析无头service

cat<<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  containers:
  - name: busybox
    image: busybox:1.28
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
  restartPolicy: Always
EOF

[root@k8s-master01 ~]# kubectl exec -ti busybox -- sh
/ # ls
bin   dev   etc   home  proc  root  sys   tmp   usr   var
/ # nslookup web-0.nginx
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      web-0.nginx
Address 1: 10.244.32.152 web-0.nginx.default.svc.cluster.local
/ # exit
StatefulSet扩容和缩容

和Deployment类似，可以通过更新replicas字段扩容/缩容StatefulSet，也可以使用kubectlscale或者kubectlpatch来扩容/缩容一个StatefulSet。

扩容

将上述创建的sts副本增加到5个（扩容之前必须保证有创建完成的静态PV，动态PV和emptyDir）：

[root@k8s-master01 2.2.7]# kubectl scale sts web --replicas=5
statefulset.apps/web scaled

查看Pod状态：

[root@k8s-master01 2.2.7]# kubectl get po
NAME   READY  STATUS  RESTARTS  AGE
web-0  1/1   Running  0     2m58s
web-1  1/1   Running  0     2m48s
web-2  1/1   Running  0     116s
web-3  1/1   Running  0     79s
web-4  1/1   Running  0     53s

也可使用以下命令动态查看：

# kubectl get pods -w -l app=nginx
缩容

在一个终端动态查看：

[root@k8s-master01 2.2.7]# kubectl get pods -w -l app=nginx
NAME  READY  STATUS  RESTARTS  AGE
web-0  1/1   Running  0     4m37s
web-1  1/1   Running  0     4m27s
web-2  1/1   Running  0     3m35s
web-3  1/1   Running  0     2m58s
web-4  1/1   Running  0     2m32s

在另一个终端将副本数改为3：

[root@k8s-master01 ~]# kubectl patch sts web -p '{"spec":{"replicas":3}}'
statefulset.apps/web patched

此时可以看到第一个终端显示web-4和web-3的Pod正在被删除（或终止）：

[root@k8s-master01 2.2.7]# kubectl get pods -w -l app=nginx
NAME  READY  STATUS  RESTARTS  AGE
web-0  1/1   Running  0     4m37s
web-1  1/1   Running  0     4m27s
web-2  1/1   Running  0     3m35s
web-3  1/1   Running  0     2m58s
web-4  1/1   Running  0     2m32s
web-0  1/1  Running  0   5m8s
web-0  1/1  Running  0   5m11s
web-4  1/1  Terminating  0   3m36s
web-4  0/1  Terminating  0   3m38s
web-4  0/1  Terminating  0   3m47s
web-4  0/1  Terminating  0   3m47s
web-3  1/1  Terminating  0   4m13s
web-3  0/1  Terminating  0   4m14s
web-3  0/1  Terminating  0   4m22s
web-3  0/1  Terminating  0   4m22s
更新策略
On Delete策略

OnDelete更新策略实现了传统（1.7版本之前）的行为，它也是默认的更新策略。当我们选择这个更新策略并修改StatefulSet的.spec.template字段时，StatefulSet控制器不会自动更新Pod，我们必须手动删除Pod才能使控制器创建新的Pod。

RollingUpdate策略

RollingUpdate（滚动更新）更新策略会更新一个StatefulSet中所有的Pod，采用与序号索引相反的顺序进行滚动更新。

比如Patch一个名称为web的StatefulSet来执行RollingUpdate更新：

[root@k8s-master01 2.2.7]# kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'
statefulset.apps/web patched

查看更改后的StatefulSet：

[root@k8s-master01 2.2.7]# kubectl get sts web -o yaml | grep -A 1 "updateStrategy"
 updateStrategy:
  type: RollingUpdate

然后改变容器的镜像进行滚动更新：

[root@k8s-master01 2.2.7]# kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"dotbalo/canary:v1"}]'
statefulset.apps/web patched

如上所述，StatefulSet里的Pod采用和序号相反的顺序更新。在更新下一个Pod前，StatefulSet控制器会终止每一个Pod并等待它们变成Running和Ready状态。在当前顺序变成Running和Ready状态之前，StatefulSet控制器不会更新下一个Pod，但它仍然会重建任何在更新过程中发生故障的Pod，使用它们当前的版本。已经接收到请求的Pod将会被恢复为更新的版本，没有收到请求的Pod则会被恢复为之前的版本。

在更新过程中可以使用 kubectl rollout status sts/ 来查看滚动更新的状态：

[root@k8s-master01 2.2.7]# kubectl rollout status sts/web
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 1 pods at revision web-56b5798f76...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 2 pods at revision web-56b5798f76...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
statefulset rolling update complete 3 pods at revision web-56b5798f76...

查看更新后的镜像：

[root@k8s-master01 2.2.7]# for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
dotbalo/canary:v1
dotbalo/canary:v1
dotbalo/canary:v1
分段更新

StatefulSet可以使用RollingUpdate更新策略的partition参数来分段更新一个StatefulSet。分段更新将会使StatefulSet中其余的所有Pod（序号小于分区）保持当前版本，只更新序号大于等于分区的Pod，利用此特性可以简单实现金丝雀发布（灰度发布）或者分阶段推出新功能等。注：金丝雀发布是指在黑与白之间能够平滑过渡的一种发布方式。

比如我们定义一个分区"partition":3，可以使用patch直接对StatefulSet进行设置：

# kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'
statefulset "web" patched

然后再次patch改变容器的镜像：

# kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]'
statefulset "web" patched

删除Pod触发更新：

#kubectl delete po web-2
pod "web-2" deleted

此时，因为Pod web-2的序号小于分区3，所以Pod不会被更新，还是会使用以前的容器恢复Pod。

将分区改为2，此时会自动更新web-2（因为之前更改了更新策略），但是不会更新web-0和web-1：

# kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'
statefulset "web" patched

按照上述方式，可以实现分阶段更新，类似于灰度/金丝雀发布。查看最终的结果如下：

[root@k8s-master01 2.2.7]# for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
dotbalo/canary:v1
dotbalo/canary:v1
dotbalo/canary:v2
删除StatefulSet

删除StatefulSet有两种方式，即级联删除和非级联删除。使用非级联方式删除StatefulSet时，StatefulSet的Pod不会被删除；使用级联删除时，StatefulSet和它的Pod都会被删除。

非级联删除

使用kubectldeletestsxxx删除StatefulSet时，只需提供–cascade=false参数，就会采用非级联删除，此时删除StatefulSet不会删除它的Pod：

[root@k8s-master01 2.2.7]# kubectl get po 
NAME  READY  STATUS  RESTARTS  AGE
web-0  1/1   Running  0     16m
web-1  1/1   Running  0     16m
web-2  1/1   Running  0     11m

[root@k8s-master01 2.2.7]# kubectl delete statefulset web --cascade=false
statefulset.apps "web" deleted

[root@k8s-master01 2.2.7]# kubectl get sts
No resources found.

[root@k8s-master01 2.2.7]# kubectl get po
NAME  READY  STATUS  RESTARTS  AGE
web-0  1/1   Running  0     16m
web-1  1/1   Running  0     16m
web-2  1/1   Running  0     11m

由于此时删除了StatefulSet，因此单独删除Pod时，不会被重建：

[root@k8s-master01 2.2.7]# kubectl get po
NAME  READY  STATUS  RESTARTS  AGE
web-0  1/1   Running  0     16m
web-1  1/1   Running  0     16m
web-2  1/1   Running  0     11m

[root@k8s-master01 2.2.7]# kubectl delete po web-0
pod "web-0" deleted

[root@k8s-master01 2.2.7]# kubectl get po
NAME  READY  STATUS  RESTARTS  AGE
web-1  1/1   Running  0     18m
web-2  1/1   Running  0     12m

当再次创建此StatefulSet时，web-0会被重新创建，web-1由于已经存在而不会被再次创建，因为最初此StatefulSet的replicas是2，所以web-2会被删除，如下（忽略AlreadyExists错误）：

[root@k8s-master01 2.2.7]# kubectl create -f sts-web.yaml 
statefulset.apps/web created
Error from server (AlreadyExists): error when creating "sts-web.yaml": services "nginx" already exists

[root@k8s-master01 2.2.7]# kubectl get po
NAME  READY  STATUS  RESTARTS  AGE
web-0  1/1   Running  0     32s
web-1  1/1   Running  0     19m
级联删除

省略–cascade=false参数即为级联删除：

[root@k8s-master01 2.2.7]# kubectl delete statefulset web
statefulset.apps "web" deleted

[root@k8s-master01 2.2.7]# kubectl get po
No resources found.

也可以使用-f参数直接删除StatefulSet和Service（此文件将sts和svc写在了一起）：

[root@k8s-master01 2.2.7]# kubectl delete -f sts-web.yaml 
service "nginx" deleted
Error from server (NotFound): error when deleting "sts-web.yaml": statefulsets.apps "web" not found

Label和 Selector

当Kubernetes对系统的任何API对象如Pod和节点进行“分组”时，会对其添加Label（key=value形式的“键-值对”）用以精准地选择对应的API对象。而Selector（标签选择器）则是针对匹配对象的查询方法。注：键-值对就是key-value pair。

例如，常用的标签tier可用于区分容器的属性，如frontend、backend；或者一个release_track用于区分容器的环境，如canary、production等。

定义Label

应用案例：

公司与xx银行有一条专属的高速光纤通道，此通道只能与192.168.7.0网段进行通信，因此只能将与xx银行通信的应用部署到192.168.7.0网段所在的节点上，此时可以对节点进行Label（即加标签）：

[root@k8s-master01 ~]# kubectl label node k8s-node02 region=subnet7
node/k8s-node02 labeled

然后，可以通过Selector对其筛选：

[root@k8s-master01 ~]# kubectl get no -l region=subnet7

NAME STATUS ROLES AGE VERSION

k8s-node02 Ready 3d17h v1.17.3

最后，在Deployment或其他控制器中指定将Pod部署到该节点：

containers:
 ......
dnsPolicy: ClusterFirst
nodeSelector:
region: subnet7
restartPolicy: Always
......

也可以用同样的方式对Service进行Label：

[root@k8s-master01 ~]# kubectl label svc canary-v1 -n canary-production env=canary version=v1
service/canary-v1 labeled

查看Labels：

[root@k8s-master01 ~]# kubectl get svc -n canary-production --show-labels
NAME    TYPE    CLUSTER-IP   EXTERNAL-IP  PORT(S)  AGE  LABELS
canary-v1  ClusterIP  10.110.253.62  <none>    8080/TCP  24h  env=canary,version=v1

还可以查看所有Version为v1的svc：

[root@k8s-master01 canary]# kubectl get svc --all-namespaces -l version=v1
NAMESPACE      NAME    TYPE    CLUSTER-IP   EXTERNAL-IP  PORT(S)  AGE
canary-production  canary-v1  ClusterIP  10.110.253.62  <none>    8080/TCP  25h

其他资源的Label方式相同。

Selector条件匹配

Selector主要用于资源的匹配，只有符合条件的资源才会被调用或使用，可以使用该方式对集群中的各类资源进行分配。

假如对Selector进行条件匹配，目前已有的Label如下：

[root@k8s-master01 ~]# kubectl get svc --show-labels
NAME     TYPE    CLUSTER-IP    EXTERNAL-IP  PORT(S)  AGE   LABELS
details    ClusterIP  10.99.9.178   <none>    9080/TCP  45h   app=details
kubernetes  ClusterIP  10.96.0.1    <none>    443/TCP  3d19h  component=apiserver,provider=kubernetes
nginx     ClusterIP  10.106.194.137  <none>    80/TCP   2d21h  app=productpage,version=v1
nginx-v2   ClusterIP  10.108.176.132  <none>    80/TCP   2d20h  <none>
productpage  ClusterIP  10.105.229.52  <none>    9080/TCP  45h   app=productpage,tier=frontend
ratings    ClusterIP  10.96.104.95   <none>    9080/TCP  45h   app=ratings
reviews    ClusterIP  10.102.188.143  <none>    9080/TCP  45h   app=reviews

选择app为reviews或者productpage的svc：

[root@k8s-master01 ~]# kubectl get svc -l 'app in (details, productpage)' --show-labels
NAME     TYPE    CLUSTER-IP    EXTERNAL-IP  PORT(S)  AGE   LABELS
details    ClusterIP  10.99.9.178   <none>    9080/TCP  45h   app=details
nginx     ClusterIP  10.106.194.137  <none>    80/TCP   2d21h  app=productpage,version=v1
productpage  ClusterIP  10.105.229.52  <none>    9080/TCP  45h   app=productpage,tier=frontend

选择app为productpage或reviews但不包括version=v1的svc：

[root@k8s-master01 ~]# kubectl get svc -l version!=v1,'app in (details, productpage)' --show-labels
NAME     TYPE    CLUSTER-IP   EXTERNAL-IP  PORT(S)  AGE  LABELS
details    ClusterIP  10.99.9.178   <none>    9080/TCP  45h  app=details
productpage  ClusterIP  10.105.229.52  <none>    9080/TCP  45h  app=productpage,tier=frontend

选择labelkey名为app的svc：

[root@k8s-master01 ~]# kubectl get svc -l app --show-labels
NAME     TYPE    CLUSTER-IP    EXTERNAL-IP  PORT(S)  AGE   LABELS
details    ClusterIP  10.99.9.178   <none>    9080/TCP  45h   app=details
nginx     ClusterIP  10.106.194.137  <none>    80/TCP   2d21h  app=productpage,version=v1
productpage  ClusterIP  10.105.229.52  <none>    9080/TCP  45h   app=productpage,tier=frontend
ratings    ClusterIP  10.96.104.95   <none>    9080/TCP  45h   app=ratings
reviews    ClusterIP  10.102.188.143  <none>    9080/TCP  45h   app=reviews
修改标签（Label）

在实际使用中，Label的更改是经常发生的事情，可以使用overwrite参数修改标签。

修改标签，比如将version=v1改为version=v2：

[root@k8s-master01 canary]# kubectl get svc -n canary-production --show-labels
NAME    TYPE    CLUSTER-IP   EXTERNAL-IP  PORT(S)  AGE  LABELS
canary-v1  ClusterIP  10.110.253.62  <none>    8080/TCP  26h  env=canary,version=v1

[root@k8s-master01 canary]# kubectl label svc canary-v1 -n canary-production version=v2 **--overwrite**
service/canary-v1 labeled

[root@k8s-master01 canary]# kubectl get svc -n canary-production --show-labels
NAME    TYPE    CLUSTER-IP   EXTERNAL-IP  PORT(S)  AGE  LABELS
canary-v1  ClusterIP  10.110.253.62  <none>    8080/TCP  26h  env=canary,version=v2
2.2.4.4 删除标签（Label）

删除标签，比如删除version：

[root@k8s-master01 canary]# kubectl label svc canary-v1 -n canary-production **version-**
service/canary-v1 labeled

[root@k8s-master01 canary]# kubectl get svc -n canary-production --show-labels
NAME    TYPE    CLUSTER-IP   EXTERNAL-IP  PORT(S)  AGE  LABELS
canary-v1  ClusterIP  10.110.253.62  <none>    8080/TCP  26h  env=canary

Service

Service主要用于Pod之间的通信，对于Pod的IP地址而言，Service是提前定义好并且是不变的资源类型。

Service可以简单的理解为逻辑上的一组Pod。一种可以访问Pod的策略，而且其他Pod可以通过这个Service访问到这个Service代理的Pod。相对于Pod而言，它会有一个固定的名称，一旦创建就固定不变。

基本概念

Kubernetes Pod具有生命周期的概念，它可以被创建、删除、销毁，一旦被销毁就意味着生命周期的结束。通过ReplicaSet能够动态地创建和销毁Pod，例如进行扩缩容和执行滚动升级。每个Pod都会获取到它自己的IP地址，但是这些IP地址不总是稳定和可依赖的，这样就会导致一个问题：在Kubernetes集群中，如果一组Pod（比如后端的Pod）为其他Pod（比如前端的Pod）提供服务，那么如果它们之间使用Pod的IP地址进行通信，在Pod重建后，将无法再进行连接。

为了解决上述问题，Kubernetes引用了Service这样一种抽象概念：逻辑上的一组Pod，即一种可以访问Pod的策略——通常称为微服务。这一组Pod能够被Service访问到，通常是通过Label Selector（标签选择器）实现的。

举个例子，有一个用作图片处理的backend（后端），运行了3个副本，这些副本是可互换的，所以frontend（前端）不需要关心它们调用了哪个backend副本，然而组成这一组backend程序的Pod实际上可能会发生变化，即便这样frontend也没有必要知道，而且也不需要跟踪这一组backend的状态，因为Service能够解耦这种关联。

对于Kubernetes集群中的应用，Kubernetes提供了简单的Endpoints API，只要Service中的一组Pod发生变更，应用程序就会被更新。对非Kubernetes集群中的应用，Kubernetes提供了基于VIP的网桥的方式访问Service，再由Service重定向到backend Pod。

定义Service

一个Service在Kubernetes中是一个REST对象，和Pod类似。像所有REST对象一样，Service的定义可以基于POST方式，请求APIServer创建新的实例。例如，假定有一组Pod，它们暴露了9376端口，同时具有app=MyApp标签。此时可以定义Service如下：

kind: Service
apiVersion: v1
metadata:
 name: my-service
spec:
 selector:
  app: MyApp
 ports:
 - protocol: TCP
   port: 80
   targetPort: 9376

上述配置创建一个名为my-service的Service对象，它会将请求代理到TCP端口为9376并且具有标签app=MyApp的Pod上。这个Service会被分配一个IP地址，通常称为ClusterIP，它会被服务的代理使用。

需要注意的是，Service能够将一个接收端口映射到任意的targetPort。默认情况下，targetPort将被设置为与Port字段相同的值。targetPort可以设置为一个字符串，引用backend Pod的一个端口的名称。

# cat nginx-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  progressDeadlineSeconds: 600
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.15.2
        imagePullPolicy: IfNotPresent
        name: nginx
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      
# cat nginx-svc.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-svc
  name: nginx-svc
spec:
  ports:
  - name: http # Service端口的名称
    port: 80 # Service自己的端口, servicea --> serviceb http://serviceb,  http://serviceb:8080 
    protocol: TCP # UDP TCP SCTP default: TCP
    targetPort: 80 # 后端应用的端口
  - name: https
    port: 443
    protocol: TCP
    targetPort: 443
  selector:
    app: nginx
  sessionAffinity: None
  type: ClusterIP
定义没有Selector的Service

Service抽象了该如何访问Kubernetes Pod，但也能够抽象其他类型的backend，例如：

  • 希望在生产环境中访问外部的数据库集群。

  • 希望Service指向另一个NameSpace中或其他集群中的服务。

  • 正在将工作负载转移到Kubernetes集群，和运行在Kubernetes集群之外的backend。

在任何这些场景中，都能定义没有Selector的Service：

kind: Service
apiVersion: v1
metadata:
 name: my-service
spec:
 ports:
 - protocol: TCP
   port: 80
   targetPort: 9376

由于这个Service没有Selector，就不会创建相关的Endpoints对象，可以手动将Service映射到指定的Endpoints：

kind: Endpoints
apiVersion: v1
metadata:
 name: my-service
subsets:
- addresses:
  - ip: 1.2.3.4
  ports:
  - port: 9376

注 意

Endpoint IP 地址不能是 loopback（127.0.0.0/8）、link-local（169.254.0.0/16）或者link-local 多播地址（224.0.0.0/24）。

访问没有Selector的Service与有Selector的Service的原理相同。请求将被路由到用户定义的Endpoint，该示例为1.2.3.4:9376。

ExternalName Service是Service的特例，它没有Selector，也没有定义任何端口和Endpoint，它通过返回该外部服务的别名来提供服务。

比如当查询主机my-service.prod.svc时，集群的DNS服务将返回一个值为my.database.example.com的CNAME记录：

kind: Service
apiVersion: v1
metadata:
 name: my-service
 namespace: prod
spec:
 type: ExternalName
 externalName: my.database.example.com
多端口Service

在许多情况下，Service可能需要暴露多个端口，对于这种情况Kubernetes支持Service定义多个端口，但使用多个端口时，必须提供所有端口的名称，例如：

kind: Service
apiVersion: v1
metadata:
 name: my-service
spec:
 selector:
  app: MyApp
 ports:
 - name: http
  protocol: TCP
  port: 80
  targetPort: 9376
 - name: https
  protocol: TCP
  port: 443
  targetPort: 9377
发布服务/服务类型

对于应用程序的某些部分（例如前端），一般要将服务公开到集群外部供用户访问。这种情况下都是用Ingress通过域名进行访问。

Kubernetes ServiceType（服务类型）主要包括以下几种：

  • ClusterIP：在集群内部使用，默认值，只能从集群中访问。

  • NodePort：在所有节点上打开一个端口，此端口可以代理至后端Pod，可以通过NodePort从集群外部访问集群内的服务，格式为NodeIP:NodePort。

  • LoadBalancer：使用云提供商的负载均衡器公开服务，成本较高。

  • ExternalName：通过返回定义的CNAME别名，没有设置任何类型的代理，需要1.7或更高版本kube-dns支持。

以NodePort为例。如果将type字段设置为NodePort，则Kubernetes将从–service-node-port-range参数指定的范围（默认为30000-32767）中自动分配端口，也可以手动指定NodePort，并且每个节点将代理该端口到Service。

ClusterIP：在集群内部使用，也是默认值。

ExternalName：通过返回定义的CNAME别名。

NodePort：在所有安装了kube-proxy的节点上打开一个端口，此端口可以代理至后端Pod，然后集群外部可以使用节点的IP地址和NodePort的端口号访问到集群Pod的服务。NodePort端口范围默认是30000-32767。

LoadBalancer：使用云提供商的负载均衡器公开服务。

一般格式如下：

kind: Service
apiVersion: v1
metadata:
 labels:
  k8s-app: kubernetes-dashboard
 name: kubernetes-dashboard
 namespace: kube-system
spec:
 type: NodePort
 ports:
 - port: 443
   targetPort: 8443
   nodePort: 30000
 selector:
  k8s-app: kubernetes-dashboard

常用的服务访问是NodePort和Ingress（关于Ingress参看2.2.14节），其他服务访问方式详情参看以下网址：

https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types

使用Service代理k8s外部应用

使用场景：

  • 希望在生产环境中使用某个固定的名称而非IP地址进行访问外部的中间件服务

  • 希望Service指向另一个Namespace中或其他集群中的服务

  • 某个项目正在迁移至k8s集群，但是一部分服务仍然在集群外部，此时可以使用service代理至k8s集群外部的服务

# cat nginx-svc-external.yaml 
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-svc-external
  name: nginx-svc-external
spec:
  ports:
  - name: http # Service端口的名称
    port: 80 # Service自己的端口, servicea --> serviceb http://serviceb,  http://serviceb:8080 
    protocol: TCP # UDP TCP SCTP default: TCP
    targetPort: 80 # 后端应用的端口
  sessionAffinity: None
  type: ClusterIP


# cat nginx-ep-external.yaml 
apiVersion: v1
kind: Endpoints
metadata:
  labels:
    app: nginx-svc-external
  name: nginx-svc-external
  namespace: default
subsets:
- addresses:
  - ip: 140.205.94.189 
  ports:
  - name: http
    port: 80
    protocol: TCP
使用Service反代域名
# cat nginx-externalName.yaml 
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-externalname
  name: nginx-externalname
spec:
  type: ExternalName
  externalName: www.baidu.com

Ingress

Ingress为Kubernetes集群中的服务提供了入口，可以提供负载均衡、SSL终止和基于名称的虚拟主机，在生产环境中常用的Ingress有Treafik、Nginx、HAProxy、Istio等。

通俗来讲，ingress和之前提到的Service、Deployment，也是一个k8s的资源类型，ingress用于实现用域名的方式访问k8s内部应用。

Ingress 安装

首先安装helm管理工具：https://helm.sh/docs/intro/install/

使用helm安装ingress：https://kubernetes.github.io/ingress-nginx/deploy/#using-helm

  1. 添加ingress的helm仓库
# helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
  1. 下载ingress的helm包至本地
# helm pull ingress-nginx/ingress-nginx
  1. 更改对应的配置
tar xf ingress-nginx-3.6.0.tgz

cd ingress-nginx

vim values.yaml
  1. 需要修改的位置

  • Controller和admissionWebhook的镜像地址，需要将公网镜像同步至公司内网镜像仓库（不一致的版本，需要自行同步gcr镜像的，可以百度查一下使用阿里云同步gcr的镜像，也可以参考这个连接https://blog.youkuaiyun.com/weixin_39961559/article/details/80739352，或者参考这个连接： https://blog.youkuaiyun.com/sinat_35543900/article/details/103290782）

  • hostNetwork设置为true

  • dnsPolicy设置为 ClusterFirstWithHostNet

  • NodeSelector添加ingress: "true"部署至指定节点

  • 类型更改为kind: DaemonSet

  1. 部署ingress

给需要部署ingress的节点上打标签

# kubectl label node k8s-master03 ingress=true

# kubectl create ns ingress-nginx

#helm install ingress-nginx -n ingress-nginx .
  1. 将ingress controller部署至Node节点（ingress controller不能部署在master节点，需要安装视频中的步骤将ingress controller部署至Node节点，生产环境最少三个ingress controller，并且最好是独立的节点）
# kubectl label node k8s-node01 ingress=true

# kubectl label node k8s-master03 ingress-
基本概念

在Kubernetesv 1.1版中添加的Ingress用于从集群外部到集群内部Service的HTTP和HTTPS路由，流量从Internet到Ingress再到Services最后到Pod上，通常情况下，Ingress部署在所有的Node节点上。

Ingress可以配置提供服务外部访问的URL、负载均衡、终止SSL，并提供基于域名的虚拟主机。但Ingress不会暴露任意端口或协议。

创建一个Ingress

创建一个简单的Ingress如下：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
 name: simple-fanout-example
 annotations:
  nginx.ingress.kubernetes.io/rewrite-target: /
spec:
 rules:
 - host: foo.bar.com
  http:
   paths:
   - path: /foo
    backend:
      serviceName: service1
      servicePort: 4200
   - path: /bar
    backend:
     serviceName: service2
     servicePort: 8080

上述host定义该Ingress的域名，将其解析至任意Node上即可访问。

如果访问的是foo.bar.com/foo，则被转发到service1的4200端口。

如果访问的是foo.bar.com/bar，则被转发到service2的8080端口。

创建一个ingress：

# cat ingress.yaml

apiVersion: networking.k8s.io/v1beta1 # networking.k8s.io/v1 / extensions/v1beta1 
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: "nginx"
  name: example
spec:
  rules: # 一个Ingress可以配置多个rules
  - host: foo.bar.com # 域名配置，可以不写，匹配*， *.bar.com
    http:
      paths: # 相当于nginx的location配合，同一个host可以配置多个path / /abc
      - backend:
          serviceName: nginx-svc 
          servicePort: 80
        path: /

创建一个多域名ingress

# cat ingress-mulDomain.yaml 

apiVersion: networking.k8s.io/v1beta1 # networking.k8s.io/v1 / extensions/v1beta1 
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: "nginx"
  name: example
spec:
  rules: # 一个Ingress可以配置多个rules
  - host: foo.bar.com # 域名配置，可以不写，匹配*， *.bar.com
    http:
      paths: # 相当于nginx的location配合，同一个host可以配置多个path / /abc
      - backend:
          serviceName: nginx-svc 
          servicePort: 80
        path: /
  - host: foo2.bar.com # 域名配置，可以不写，匹配*， *.bar.com
    http:
      paths: # 相当于nginx的location配合，同一个host可以配置多个path / /abc
      - backend:
          serviceName: nginx-svc-external
          servicePort: 80
        path: /
Ingress Rules

host：可选，一般都会配置对应的域名。

path：每个路径都有一个对应的serviceName和servicePort，在流量到达服务之前，主机和路径都会与传入请求的内容匹配。

backend：描述Service和Port的组合。对Ingress匹配主机和路径的HTTP与HTTPS请求将被发送到对应的后端。

默认后端

没有匹配到任何规则的流量将被发送到默认后端。默认后端通常是Ingress Controller的配置选项，并未在Ingress资源中指定。

Ingress类型
单域名

单个域名匹配多个path到不同的service：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
 name: simple-fanout-example
 annotations:
   nginx.ingress.kubernetes.io/rewrite-target: /
spec:
 rules:
 - host: foo.bar.com
  http:
   paths:
   - path: /foo
    backend:
     serviceName: service1
     servicePort: 4200
   - path: /bar
    backend:
     serviceName: service2
     servicePort: 8080

此时，访问foo.bar.com/foo到service1的4200。访问foo.bar.com/bar到service2的8080。

多域名

基于域名的虚拟主机支持将HTTP流量路由到同一IP地址的多个主机名：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
 name: name-virtual-host-ingress
spec:
 rules:
 - host: foo.bar.com
  http:
   paths:
   - backend:
     serviceName: service1
     servicePort: 80
 - host: bar.foo.com
  http:
   paths:
   - backend:
     serviceName: service2
     servicePort: 80

此时，访问foo.bar.com到service1，访问bar.foo.com到service2。

基于TLS的Ingress

首先创建证书，生产环境的证书为公司购买的证书：

kubectl -n default create secret tls nginx-test-tls --key=tls.key --cert=tls.crt

定义Ingress（此示例为Traefik，nginx-ingress将traefik改为nginx即可）：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
 name: nginx-https-test
 namespace: default
 annotations:
  kubernetes.io/ingress.class: traefik
spec:
 rules:
 - host: traefix-test.com
  http:
   paths:
   - backend:
      serviceName: nginx-svc
      servicePort: 80
 tls:
 - secretName: nginx-test-tls

Ingress.yaml

apiVersion: v1
kind: Namespace
metadata:
name: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx

---
# Source: ingress-nginx/templates/controller-serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
helm.sh/chart: ingress-nginx-3.23.0
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/version: 0.44.0
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/component: controller
name: ingress-nginx
namespace: ingress-nginx
---
# Source: ingress-nginx/templates/controller-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
labels:
helm.sh/chart: ingress-nginx-3.23.0
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/version: 0.44.0
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/component: controller
name: ingress-nginx-controller
namespace: ingress-nginx
data:
---
# Source: ingress-nginx/templates/clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
helm.sh/chart: ingress-nginx-3.23.0
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/version: 0.44.0
app.kubernetes.io/managed-by: Helm
name: ingress-nginx
rules:
- apiGroups:
    - ''
  resources:
    - configmaps
    - endpoints
    - nodes
    - pods
    - secrets
  verbs:
    - list
    - watch
- apiGroups:
    - ''
  resources:
    - nodes
  verbs:
    - get
- apiGroups:
    - ''
  resources:
    - services
  verbs:
    - get
    - list
    - watch
- apiGroups:
    - extensions
    - networking.k8s.io   # k8s 1.14+
  resources:
    - ingresses
  verbs:
    - get
    - list
    - watch
- apiGroups:
    - ''
  resources:
    - events
  verbs:
    - create
    - patch
- apiGroups:
    - extensions
    - networking.k8s.io   # k8s 1.14+
  resources:
    - ingresses/status
  verbs:
    - update
- apiGroups:
    - networking.k8s.io   # k8s 1.14+
  resources:
    - ingressclasses
  verbs:
    - get
    - list
    - watch
---
# Source: ingress-nginx/templates/clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
name: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: ingress-nginx
subjects:
- kind: ServiceAccount
  name: ingress-nginx
  namespace: ingress-nginx
---
# Source: ingress-nginx/templates/controller-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: controller
name: ingress-nginx
namespace: ingress-nginx
rules:
- apiGroups:
    - ''
  resources:
    - namespaces
  verbs:
    - get
- apiGroups:
    - ''
  resources:
    - configmaps
    - pods
    - secrets
    - endpoints
  verbs:
    - get
    - list
    - watch
- apiGroups:
    - ''
  resources:
    - services
  verbs:
    - get
    - list
    - watch
- apiGroups:
    - extensions
    - networking.k8s.io   # k8s 1.14+
  resources:
    - ingresses
  verbs:
    - get
    - list
    - watch
- apiGroups:
    - extensions
    - networking.k8s.io   # k8s 1.14+
  resources:
    - ingresses/status
  verbs:
    - update
- apiGroups:
    - networking.k8s.io   # k8s 1.14+
  resources:
    - ingressclasses
  verbs:
    - get
    - list
    - watch
- apiGroups:
    - ''
  resources:
    - configmaps
  resourceNames:
    - ingress-controller-leader-nginx
  verbs:
    - get
    - update
- apiGroups:
    - ''
  resources:
    - configmaps
  verbs:
    - create
- apiGroups:
    - ''
  resources:
    - events
  verbs:
    - create
    - patch
---
# Source: ingress-nginx/templates/controller-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: controller
name: ingress-nginx
namespace: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: ingress-nginx
subjects:
- kind: ServiceAccount
  name: ingress-nginx
  namespace: ingress-nginx
---
# Source: ingress-nginx/templates/controller-service-webhook.yaml
apiVersion: v1
kind: Service
metadata:
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: controller
name: ingress-nginx-controller-admission
namespace: ingress-nginx
spec:
type: ClusterIP
ports:
  - name: https-webhook
    port: 443
    targetPort: webhook
selector:
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/component: controller
---
# Source: ingress-nginx/templates/controller-service.yaml
apiVersion: v1
kind: Service
metadata:
annotations:
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: controller
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
type: NodePort
ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: http
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
selector:
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/component: controller
---
# Source: ingress-nginx/templates/controller-deployment.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: controller
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
selector:
  matchLabels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/component: controller
revisionHistoryLimit: 10
minReadySeconds: 0
template:
  metadata:
    labels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/instance: ingress-nginx
      app.kubernetes.io/component: controller
  spec:
    dnsPolicy: ClusterFirstWithHostNet 
    hostNetwork: true
    containers:
      - name: controller
        image: registry.cn-beijing.aliyuncs.com/dotbalo/controller:v0.44.0
        imagePullPolicy: IfNotPresent
        lifecycle:
          preStop:
            exec:
              command:
                - /wait-shutdown
        args:
          - /nginx-ingress-controller
          - --election-id=ingress-controller-leader
          - --ingress-class=nginx
          - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
          - --validating-webhook=:8443
          - --validating-webhook-certificate=/usr/local/certificates/cert
          - --validating-webhook-key=/usr/local/certificates/key
        securityContext:
          capabilities:
            drop:
              - ALL
            add:
              - NET_BIND_SERVICE
          runAsUser: 101
          allowPrivilegeEscalation: true
        env:
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: LD_PRELOAD
            value: /usr/local/lib/libmimalloc.so
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 5
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 3
        ports:
          - name: http
            containerPort: 80
            protocol: TCP
          - name: https
            containerPort: 443
            protocol: TCP
          - name: webhook
            containerPort: 8443
            protocol: TCP
        volumeMounts:
          - name: webhook-cert
            mountPath: /usr/local/certificates/
            readOnly: true
        resources:
          requests:
            cpu: 100m
            memory: 90Mi
    nodeSelector:
      kubernetes.io/os: linux
      ingress: "true"
    serviceAccountName: ingress-nginx
    terminationGracePeriodSeconds: 300
    volumes:
      - name: webhook-cert
        secret:
          secretName: ingress-nginx-admission
---
# Source: ingress-nginx/templates/admission-webhooks/validating-webhook.yaml
# before changing this value, check the required kubernetes version
# https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#prerequisites
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: admission-webhook
name: ingress-nginx-admission
webhooks:
- name: validate.nginx.ingress.kubernetes.io
  matchPolicy: Equivalent
  rules:
    - apiGroups:
        - networking.k8s.io
      apiVersions:
        - v1beta1
      operations:
        - CREATE
        - UPDATE
      resources:
        - ingresses
  failurePolicy: Fail
  sideEffects: None
  admissionReviewVersions:
    - v1
    - v1beta1
  clientConfig:
    service:
      namespace: ingress-nginx
      name: ingress-nginx-controller-admission
      path: /networking/v1beta1/ingresses
---
# Source: ingress-nginx/templates/admission-webhooks/job-patch/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: ingress-nginx-admission
annotations:
  helm.sh/hook: pre-install,pre-upgrade,post-install,post-upgrade
  helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: admission-webhook
namespace: ingress-nginx
---
# Source: ingress-nginx/templates/admission-webhooks/job-patch/clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: ingress-nginx-admission
annotations:
  helm.sh/hook: pre-install,pre-upgrade,post-install,post-upgrade
  helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: admission-webhook
rules:
- apiGroups:
    - admissionregistration.k8s.io
  resources:
    - validatingwebhookconfigurations
  verbs:
    - get
    - update
---
# Source: ingress-nginx/templates/admission-webhooks/job-patch/clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: ingress-nginx-admission
annotations:
  helm.sh/hook: pre-install,pre-upgrade,post-install,post-upgrade
  helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: admission-webhook
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: ingress-nginx-admission
subjects:
- kind: ServiceAccount
  name: ingress-nginx-admission
  namespace: ingress-nginx
---
# Source: ingress-nginx/templates/admission-webhooks/job-patch/role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ingress-nginx-admission
annotations:
  helm.sh/hook: pre-install,pre-upgrade,post-install,post-upgrade
  helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: admission-webhook
namespace: ingress-nginx
rules:
- apiGroups:
    - ''
  resources:
    - secrets
  verbs:
    - get
    - create
---
# Source: ingress-nginx/templates/admission-webhooks/job-patch/rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: ingress-nginx-admission
annotations:
  helm.sh/hook: pre-install,pre-upgrade,post-install,post-upgrade
  helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: admission-webhook
namespace: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: ingress-nginx-admission
subjects:
- kind: ServiceAccount
  name: ingress-nginx-admission
  namespace: ingress-nginx
---
# Source: ingress-nginx/templates/admission-webhooks/job-patch/job-createSecret.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: ingress-nginx-admission-create
annotations:
  helm.sh/hook: pre-install,pre-upgrade
  helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: admission-webhook
namespace: ingress-nginx
spec:
template:
  metadata:
    name: ingress-nginx-admission-create
    labels:
      helm.sh/chart: ingress-nginx-3.23.0
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/instance: ingress-nginx
      app.kubernetes.io/version: 0.44.0
      app.kubernetes.io/managed-by: Helm
      app.kubernetes.io/component: admission-webhook
  spec:
    containers:
      - name: create
        image: registry.cn-beijing.aliyuncs.com/dotbalo/kube-webhook-certgen:v1.5.1
        imagePullPolicy: IfNotPresent
        args:
          - create
          - --host=ingress-nginx-controller-admission,ingress-nginx-controller-admission.$(POD_NAMESPACE).svc
          - --namespace=$(POD_NAMESPACE)
          - --secret-name=ingress-nginx-admission
        env:
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
    restartPolicy: OnFailure
    serviceAccountName: ingress-nginx-admission
    securityContext:
      runAsNonRoot: true
      runAsUser: 2000
---
# Source: ingress-nginx/templates/admission-webhooks/job-patch/job-patchWebhook.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: ingress-nginx-admission-patch
annotations:
  helm.sh/hook: post-install,post-upgrade
  helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded
labels:
  helm.sh/chart: ingress-nginx-3.23.0
  app.kubernetes.io/name: ingress-nginx
  app.kubernetes.io/instance: ingress-nginx
  app.kubernetes.io/version: 0.44.0
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/component: admission-webhook
namespace: ingress-nginx
spec:
template:
  metadata:
    name: ingress-nginx-admission-patch
    labels:
      helm.sh/chart: ingress-nginx-3.23.0
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/instance: ingress-nginx
      app.kubernetes.io/version: 0.44.0
      app.kubernetes.io/managed-by: Helm
      app.kubernetes.io/component: admission-webhook
  spec:
    containers:
      - name: patch
        image: registry.cn-beijing.aliyuncs.com/dotbalo/kube-webhook-certgen:v1.5.1
        imagePullPolicy: IfNotPresent
        args:
          - patch
          - --webhook-name=ingress-nginx-admission
          - --namespace=$(POD_NAMESPACE)
          - --patch-mutating=false
          - --secret-name=ingress-nginx-admission
          - --patch-failure-policy=Fail
        env:
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
    restartPolicy: OnFailure
    serviceAccountName: ingress-nginx-admission
    securityContext:
      runAsNonRoot: true
      runAsUser: 2000

ConfigMap

​ 一般用ConfigMap去管理一些配置文件、或者一些大量的环境变量信息。

​ ConfigMap将配置和Pod分开，有一个nginx，nginx.conf -> configmap,nginx

​ 更易于配置文件的更改和管理。

​ Secret：Secret更倾向于存储和共享敏感、加密的配置信息。

ConfigMap中文地址

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  nodeName: k8s-master02
  containers:
    - name: test-container
      image: busybox:1.28
      imagePullPolicy: IfNotPresent
      command: [ "/bin/sh", "-c", "env" ]
      envFrom:
      - configMapRef:
          name: special-config
      env:
        # Define the environment variable
        #- name: SPECIAL_LEVEL_KEY
        #  valueFrom:
        #    configMapKeyRef:
        #      # The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY
        #      name: special-config
        #      # Specify the key associated with the value
        #      key: special.how
        - name: test
          value: test-value
        - name: mysqlHostAddress
          value: 10.10.10.10
        - name: mysqlPort
          value: "3306" # only string
  restartPolicy: Never
创建ConfigMap的几种形式
kubectl create configmap -h
kubectl create cm cmfromdir --from-file=conf/
kubectl create cm cmfromfile --from-file=conf/redis.conf 
kubectl create cm cmspecialname --from-file=game-conf=game.conf
kubectl create cm cmspecialname2 --from-file=game-conf=game.conf  --from-file=redis-conf=redis.conf
kubectl create cm gameenvcm --from-env-file=game.conf
kubectl  create cm envfromliteral --from-literal=level=INFO --from-literal=PASSWORD=redis123
kubectl  create -f cm.yaml
使用valueFrom定义环境变量
kubectl create deploy dp-cm \ 
--image=registry.cn-beijing.aliyuncs.com/dotbalo/nginx \
--dry-run=client -oyaml > dp-cm.yaml


example 1 ：
env:
        - name: TEST_ENV
          value: testenv
        - name: LIVES
          valueFrom:
            configMapKeyRef:
              name: gameenvcm
              key: lives
        - name: test_env
          valueFrom:
            configMapKeyRef:
              name: gameenvcm
              key: test_env
example 2 ：
containers:
      - image: registry.cn-beijing.aliyuncs.com/dotbalo/nginx 
        name: nginx
        envFrom:
        - configMapRef:
            name: gameenvcm
          prefix: fromCm_
        env:
        - name: TEST_ENV
          value: testenv
        - name: LIVES
          valueFrom:
            configMapKeyRef:
              name: gameenvcm
              key: lives
        #- name: test_env
        #  valueFrom:
        #    configMapKeyRef:
        #      name: gameenvcm
        #      key: test_env
以文件的形式挂载ConfigMap
 spec:
      containers:
        - image: registry.cn-beijing.aliyuncs.com/dotbalo/nginx 
          name: nginx
          volumeMounts:
            - name: redisconf
              mountPath: /etc/config
            - name: cmfromfile 
              mountPath: /etc/config2
      volumes:
        - name: redisconf
          configMap:
            name: redis-conf
        - name: cmfromfile
          configMap:
            name: cmfromfile
自定义挂载权限及名称
volumes:
        - name: redisconf
          configMap:
            name: redis-conf
        - name: cmfromfile
          configMap:
            name: cmfromfile
            items:
              - key: redis.conf
                path: redis.conf.bak
              - key: redis.conf
                path: redis.conf.bak2
                mode: 0644 # 优先级高
            defaultMode: 0666  # 328

Secret常用类型

  • Opaque：通用型Secret，默认类型；

  • kubernetes.io/service-account-token：作用于ServiceAccount，包含一个令牌，用于标识API服务账户；

  • kubernetes.io/dockerconfigjson：下载私有仓库镜使用的Secret和宿主机的/root/.docker/config.json一致，宿主机登录后即可产生该文件；

  • kubernetes.io/basic-auth：用于使用基本认证（账号密码）的Secret，可以使用Opaque取代；

  • kubernetes.io/ssh-auth：用于存储ssh密钥的Secret；

  • kubernetes.io/tls：用于存储HTTPS域名证书文件的Secret，可以被Ingress使用；

  • bootstrap.kubernetes.io/token：一种简单的 bearer token，

    用于创建新集群或将新节点添加到现有集群，在集群安装时可用于自动颁发集群的证书。

Secret

使用Secret拉取私有仓库镜像
kubectl create secret docker-registry myregistrykey \
--docker-server=DOCKER_REGISTRY_SERVER \
--docker-username=DOCKER_USER \
--docker-password=DOCKER_PASSWORD \
--docker-email=DOCKER_EMAIL

Taint和Toleration

Taint能够使节点排斥一类特定的Pod，Taint和Toleration相互配合可以用来避免Pod被分配到不合适的节点，比如Master节点不允许部署系统组件之外的其他Pod。每个节点上都可以应用一个或多个Taint，这表示对于那些不能容忍这些Taint的Pod是不会被该节点接受的。如果将Toleration应用于Pod上，则表示这些Pod可以（但不要求）被调度到具有匹配Taint的节点上。

概念

给节点增加一个Taint：

[root@k8s-master01 2.2.8]# kubectl taint nodes k8s-node01 key=value:NoSchedule
node/k8s-node01 tainted

上述命令给k8s-node01增加一个Taint，它的key对应的就是键，value对应就是值，effect对应的就是NoSchedule。这表明只有和这个Taint相匹配的Toleration的Pod才能够被分配到k8s-node01节点上。按如下方式在PodSpec中定义Pod的Toleration，就可以将Pod部署到该节点上。

方式一：

tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"

方式二：

tolerations:
- key: "key"
  operator: "Exists"
  effect: "NoSchedule"

一个Toleration和一个Taint相匹配是指它们有一样的key和effect，并且如果operator是Exists（此时toleration不指定value）或者operator是Equal，则它们的value应该相等。

注意两种情况：

  • 如果一个Toleration的key为空且operator为Exists，表示这个Toleration与任意的key、value和effect都匹配，即这个Toleration能容忍任意的Taint：

    tolerations:
- operator: "Exists"

  • 如果一个Toleration的effect为空，则key与之相同的相匹配的Taint的effect可以是任意值：

    tolerations:
- key: "key"
  operator: "Exists"

    上述例子使用到effect的一个值NoSchedule，也可以使用PreferNoSchedule，该值定义尽量避免将Pod调度到存在其不能容忍的Taint的节点上，但并不是强制的。effect的值还可以设置为NoExecute。

一个节点可以设置多个Taint，也可以给一个Pod添加多个Toleration。Kubernetes处理多个Taint和Toleration的过程就像一个过滤器：从一个节点的所有Taint开始遍历，过滤掉那些Pod中存在与之相匹配的Toleration的Taint。余下未被过滤的Taint的effect值决定了Pod是否会被分配到该节点，特别是以下情况：

  • 如果未被过滤的Taint中存在一个以上effect值为NoSchedule的Taint，则Kubernetes不会将Pod分配到该节点。

  • 如果未被过滤的Taint中不存在effect值为NoExecute的Taint，但是存在effect值为PreferNoSchedule的Taint，则Kubernetes会尝试将Pod分配到该节点。

  • 如果未被过滤的Taint中存在一个以上effect值为NoExecute的Taint，则Kubernetes不会将Pod分配到该节点（如果Pod还未在节点上运行），或者将Pod从该节点驱逐（如果Pod已经在节点上运行）。

例如，假设给一个节点添加了以下的Taint：

# kubectl taint nodes k8s-node01 key1=value1:NoSchedule
# kubectl taint nodes k8s-node01 key1=value1:NoExecute
# kubectl taint nodes k8s-node01 key2=value2:NoSchedule

然后存在一个Pod，它有两个Toleration：

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"

在上述例子中，该Pod不会被分配到上述节点，因为没有匹配第三个Taint。但是如果给节点添加上述3个Taint之前，该Pod已经在上述节点中运行，那么它不会被驱逐，还会继续运行在这个节点上，因为第3个Taint是唯一不能被这个Pod容忍的。

通常情况下，如果给一个节点添加了一个effect值为NoExecute的Taint，则任何不能容忍这个Taint的Pod都会马上被驱逐，任何可以容忍这个Taint的Pod都不会被驱逐。但是，如果Pod存在一个effect值为NoExecute的Toleration指定了可选属性tolerationSeconds的值，则该值表示是在给节点添加了上述Taint之后Pod还能继续在该节点上运行的时间，例如：

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 3600

表示如果这个Pod正在运行，然后一个匹配的Taint被添加到其所在的节点，那么Pod还将继续在节点上运行3600秒，然后被驱逐。如果在此之前上述Taint被删除了，则Pod不会被驱逐。

删除一个Taint：
# kubectl taint nodes k8s-node01 key1:NoExecute-
查看Taint：
[root@k8s-master01 2.2.8]# kubectl describe node k8s-node01 | grep Taint
Taints:             key=value:NoSchedule
用例

通过Taint和Toleration可以灵活地让Pod避开某些节点或者将Pod从某些节点被驱逐。下面是几种情况。

（1）专用节点

如果想将某些节点专门分配给特定的一组用户使用，可以给这些节点添加一个Taint（kubectl taint nodes nodename dedicated=groupName:NoSchedule），然后给这组用户的Pod添加一个相对应的Toleration。拥有上述Toleration的Pod就能够被分配到上述专用节点，同时也能够被分配到集群中的其他节点。如果只希望这些Pod只能分配到上述专用节点中，那么还需要给这些专用节点另外添加一个和上述Taint类似的Label（例如：dedicated=groupName），然后给Pod增加节点亲和性要求或者使用NodeSelector，就能将Pod只分配到添加了dedicated=groupName标签的节点上。

（2）特殊硬件的节点

在部分节点上配备了特殊硬件（比如GPU）的集群中，我们只允许特定的Pod才能部署在这些节点上。这时可以使用Taint进行控制，添加Taint如kubectl taint nodes nodename special=true:NoSchedule或者kubectl taint nodes nodename special=true:PreferNoSchedule，然后给需要部署在这些节点上的Pod添加相匹配的Toleration即可。

（3）基于Taint的驱逐

属于alpha特性，在每个Pod中配置在节点出现问题时的驱逐行为。

基于Taint的驱逐

之前提到过Taint的effect值NoExecute，它会影响已经在节点上运行的Pod。如果Pod不能忍受effect值为NoExecute的Taint，那么Pod将会被马上驱逐。如果能够忍受effect值为NoExecute的Taint，但是在Toleration定义中没有指定tolerationSeconds，则Pod还会一直在这个节点上运行。

在Kubernetes 1.6版以后已经支持（alpha）当某种条件为真时，Node Controller会自动给节点添加一个Taint，用以表示节点的问题。当前内置的Taint包括：

  • node.kubernetes.io/not-ready：节点未准备好，相当于节点状态Ready的值为False。

  • node.kubernetes.io/unreachable：Node Controller访问不到节点，相当于节点状态Ready的值为Unknown。

  • node.kubernetes.io/out-of-disk：节点磁盘耗尽。

  • node.kubernetes.io/memory-pressure：节点存在内存压力。

  • node.kubernetes.io/disk-pressure：节点存在磁盘压力。

  • node.kubernetes.io/network-unavailable：节点网络不可达。

  • node.kubernetes.io/unschedulable：节点不可调度。

  • node.cloudprovider.kubernetes.io/uninitialized：如果Kubelet启动时指定了一个外部的cloudprovider，它将给当前节点添加一个Taint将其标记为不可用。在cloud-controller-manager的一个controller初始化这个节点后，Kubelet将删除这个Taint。

使用这个alpha功能特性，结合tolerationSeconds，Pod就可以指定当节点出现一个或全部上述问题时，Pod还能在这个节点上运行多长时间。

比如，一个使用了很多本地状态的应用程序在网络断开时，仍然希望停留在当前节点上运行一段时间，愿意等待网络恢复以避免被驱逐。在这种情况下，Pod的Toleration可以这样配置：

tolerations:
- key: "node.alpha.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 6000

注意

Kubernetes会自动给Pod添加一个key为node.kubernetes.io/not-ready的Toleration并配置tolerationSeconds=300，同样也会给Pod添加一个key为node.kubernetes.io/unreachable的Toleration并配置tolerationSeconds=300，除非用户自定义了上述key，否则会采用这个默认设置。

这种自动添加Toleration的机制保证了在其中一种问题被检测到时，Pod默认能够继续停留在当前节点运行5分钟。这两个默认Toleration是由DefaultTolerationSeconds admission controller添加的。

DaemonSet中的Pod被创建时，针对以下Taint自动添加的NoExecute的Toleration将不会指定tolerationSeconds：

  • node.alpha.kubernetes.io/unreachable

  • node.kubernetes.io/not-ready

这保证了出现上述问题时DaemonSet中的Pod永远不会被驱逐。

Rancher入门到精通-2.0 .com/yum/repos/kubernetes-el7-x86_64/repodata/repomd.xml: [Errno 12] Timeout on htt
隔壁老瓦的专栏
11-04 1626
docker-ce-stable | 3.5 kB 00:00:00 extras ...
kubernetes-helm详细介绍及使用
qq_27234433的博客
03-03 2590
致读者 完整入门示例请参考：Helm完整入门实战 Helm 本指南介绍了使用 Helm 来管理 Kubernetes 集群上的软件包的基础知识。在这之前，假定您已经 安装了 Helm 客户端。 如果您仅对运行一些快速命令感兴趣，则不妨从 快速入门指南开始。本章包含了 Helm 命令的详细说明，并解释如何使用 Helm。 三大概念 Chart 代表着 Helm 包。它包含在 Kubernetes 集群内部运行应用程序，工具或服务所需的所有资源定义。你可以把它看作是 Homebre
kubernetes&&简单模板
dfq737211338的博客
06-04 451
kubernetes&&简单模板Podinit Creadinesslivenessexechttpgettcpmain Cstart/stop Pod init C [root@k8s-master01 Pod]# cat init.yaml apiVersion: v1 kind: Pod metadata: name: myapp-pod namespace: default labels: app: myapp spec: conta
Kubernetes的template解析
专注于数据库技术分享，包含但不限于Oracle，MySQL，PostgreSQL，ElasticSearch及国产数据库等
05-06 807
在 Kubernetes 中，template是一个非常核心的概念，尤其是在创建和管理工作负载（Workloads）如 Deployments、StatefulSets、DaemonSets 等时。template是一个嵌套在这些资源定义中的 YAML 对象，用于定义 Pod 的标准结构，包括其元数据1…（metadata）、规范（spec），以及容器（containers）和其他相关配置。template使得你可以定义一组期望状态，Kubernetes 会基于这个模板自动创建和管理实际的 Pod 实例。
Kubernetes-templates:Kubernetes YAML模板-最佳实践，技巧和窍门已直接导入到生产部署模板中-加上CICD Jenkins和TeamCity，带有ACME的证书管理器让我们加密免费入口自动SSL证书，补丁，Kustomize等
03-09
Kubernetes模板 Kubernetes YAML模板。 包含在生产环境中学习到的各种最佳实践，技巧和窍门。 从 / 开始，高级用户请参阅 。 包含用于使用静态公共IP并锁定GKE生成的GCP防火墙规则，Cloudflare代理IP等的配置。 使用Jenkins和TeamCity在Kubernetes上进行高级自动缩放CI / CD。 最好的文档链接位于每个yaml的顶部，用于快速引用（此高级可以通过热键打开当前文件的URL！） 与direnv一起使用以将正确的Kubernetes上下文自动加载到当前的shell中，以避免天真的更改全局~/.kube/config上下文引起的shell和脚本之间的竞争状况 从库派生，现在这是库的子模块，后者是DevOps ， 和工具存储库的子模块。 也可以看看： -550多种DevOps Bash脚本，高级.bashrc ， .vi
Kubernetes Service 模板
weixin_30706507的博客
05-03 535
apiVersion: v1 kind: Service metadata: name: my-nginx labels: run: my-nginx spec: type: NodePort ports: - port: 8080 targetPort: 80 protocol: TCP name: http - port: 443 ...
Kubernetes基础模板解读
记录点滴生活
12-19 810
这是一个示例.yaml文件，显示了Kubernetes部署所需的字段和对象规范： application/deployment.yaml apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 kind: Deployment metadata: name: nginx-deployment spec: select...
【flink脚本系列】 kubernetes-jobmanager.sh功能用法示例源码解析
wang2leee的博客
08-27 355
该脚本用于在 Kubernetes 上启动 Flink 的 JobManager，它适用于 Flink 的原生 Kubernetes 集成。
kubernetes-volume-demo:Demo2-Kubernetes Volume Node.js应用演示
04-04
如何在k8的集群中运行此应用程序 可用路线： =>获取/故事 =>发布/故事正文：{“ text”：“存储此想法”} ... Note:即使容器崩溃，通过后路径/story存储的数据也将保留。 尽管当吊舱被移除时它将被破坏。
kubernetes-bootcamp
砚墨
09-21 1900
Kubernetes Lab 1 – Kubernetes Local Setup Kubernetes is an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts. Kubernetes seeks to foster an ecosystem of components and tools that rel.
发现Kubernetes的基石：Kubernetes Template Project深度解析与应用指南
gitblog_00051的博客
06-02 801
发现Kubernetes的基石：Kubernetes Template Project深度解析与应用指南 在开源的世界里，每个新项目都承载着开发者无尽的创意与激情，而这一切的起点常常是一份精心准备的模板。今天，我们要探讨的是——Kubernetes Template Project，这是为所有隶属于Kubernetes的GitHub组织中启动新项目设计的模板。本文将从四个方面带领您深入了解这一开源...
利用 Kubernetes 内置 PodTemplate 管理 Jenkins 构建节点
KubeSphere
09-20 1867
作者：Rick Jenkins 可以很好地与 Kubernetes 集成，不管是控制器（controller）还是构建节点（agent），都能以 Pod 的形式运行在 Kubernetes 上。 熟悉 Jenkins 的用户，都知道 Jenkins 支持多种类型的构建节点，例如：固定配置、动态配置。而节点与控制器连接的方式， 又包括：JNLP、SSH 等。对于已经在全面拥抱容器技术的用户，大多数是通过连接 Kubernetes 集群并动态启动、销毁 Pod 的方式来使用构建节点。 而随着构建节点的种类、
【K8S】Kubernetes初探
阳阳的博客
09-16 2936
K8S是什么？ K8S是Kubernetes的缩写（首字母K+中间8个字母+末尾字母S），是一个高度自动化的资源控制系统，它通过跟踪配置库里保存的“资源期望状态”与当前环境的“实际资源状态”之间的差异来实现自动控制。例如在某节点宕机时，自动迁移服务单元到新的节点上。 核心词汇解释 （1）镜像 此处的镜像和容器都是docker中的概念，不过这里的镜像与我们常用...
kubectl批量获取template配置参数
40kuai的博客
11-20 914
通过kubectl命令批量获取pod参数配置情况 kubectl get pod -n soul-tech-platformarch \ -o go-template \ --template='{{range .items}}{{range .spec.containers}}{{printf "%s\n" .resources}}{{end}}{{end}}'
K8s - 札记 - node.kubernetes.io/disk-pressure:NoSchedule
个人纪录、总结！
03-12 3069
K8s - 目录 K8s - 札记 - node.kubernetes.io/disk-pressure:NoSchedule一、问题描述1. 现象2. 原因二、解决方案三、参考命令 一、问题描述 1. 现象 pod 一直处于 pending 状态； pod 提示：Warning FailedScheduling 4m10s default-scheduler 0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io.
kubernetes上节点node.kubernetes.io/disk-pressure:NoSchedule污点导致pod 被驱逐
热门推荐
russle的专栏
07-25 1万+
现象： k8s集群中某台计算节点上pod大量pending，通过describe node发现该node上有Taints: node.kubernetes.io/disk-pressure:NoSchedule 污点。 寻找分析： 查阅文档提示磁盘不足，因为时间紧张，就快速通过df -h命令查看当前磁盘情况，并在可疑的主要目录执行du -d 1 -h |sort -hr查看文件夹大小并删除一部分无用文件。结果k8s node一直没有恢复，仔细分析才先该机器有两块磁盘，一个根分区， 一
kubectl template 一个例子
some demo
05-06 714
kubectl get secret -n kube-system -o go-template='{{range .items}}{{.metadata.namespace}} {{.metadata.name}}{{end}} 如何加换行？知道的评论下，谢谢
kubectl通过go-template获取属性
Kason_iWiki
09-10 670
文章目录背景介绍基础语法示例1 获取pod IP示例2 获取pod使用镜像的ip 背景介绍 在使用kubectl get获取资源信息的时候,可以通过-o(–output简写形式)指定信息输出的格式,如果指定的是yaml或者json输出的是资源的完整信息,实际工作中,输出内容过少则得不到我们想要的信息,输出内容过于详细又不利于快速定位的我们想要找到的内容,其实-o输出格式可以指定为go-template然后指定一个template,这样我们就可以通过go-template获取我们想要的内容.go-templa
node.kubernetes.io/disk-pressure:NoSchedule
yzhao66的博客
08-30 1721
master节点：node.kubernetes.io/disk-pressure:NoSchedule 说明硬盘不够，把不需要的镜像删除掉就恢复正常了
解决：[root@kubernetes-register harbor]# yum install -y docker-compose 已加载插件：fastestmirror Loading mirror speeds from cached hostfile * base: mirrors.aliyun.com * extras: mirrors.aliyun.com * updates: mirrors.aliyun.com 没有可用软件包 docker-compose。 错误：无须任何处理 [root@kubernetes-register harbor]# docker compose version Docker Compose version v2.27.1 [root@kubernetes-register harbor]# ./install.sh [Step 0]: checking if docker is installed ... Note: docker version: 26.1.4 [Step 1]: checking docker-compose is installed ... ✖ Need to install docker-compose(1.18.0+) by yourself first and run this script again. [root@kubernetes-register harbor]#
最新发布
04-29
<think>好的，我现在需要帮助用户解决在CentOS或RHEL系统中使用YUM安装docker-compose失败的问题，并手动安装兼容版本的docker-compose以满足Harbor的依赖需求。首先，我要回顾一下用户提供的引用内容，看看有哪些有用的信息。 用户提到了引用[1]到[4]，其中引用[2]、[3]、[4]都涉及docker-compose的安装方法，特别是手动安装的步骤。例如，引用[2]提到使用curl下载二进制文件并添加执行权限，引用[3]和[4]提到了上传文件并修改权限的步骤。用户之前的问题是关于YUM安装失败，所以需要手动安装。 接下来，我需要确定为什么YUM安装会失败。通常，CentOS/RHEL的默认仓库可能不包含docker-compose，或者版本过旧无法满足Harbor的要求。因此，手动安装最新的或特定版本的docker-compose是必要的。 根据引用内容，用户可能需要两种方法：二进制文件安装和pip安装。我需要详细说明这两种方法，并确保步骤正确。例如，二进制安装需要下载正确的版本，设置权限，验证安装。而pip安装则需要先安装Python环境，这可能在某些系统中没有预装，需要注意。 另外，用户提到Harbor的依赖需求，所以需要确认docker-compose的版本是否兼容。Harbor可能有最低版本要求，比如1.18.0或更高，因此需要指导用户选择合适的版本。 在步骤中，需要包括下载、安装、权限设置、验证以及可能的HTTP配置，因为Harbor可能需要HTTP访问，这涉及到修改docker的配置，如daemon.json或systemd文件，并重启服务。引用[1]提到了这两种方法，所以需要包含这些步骤。 还要注意可能的错误点，比如下载链接是否正确，权限是否正确，路径是否在PATH中。此外，如果用户使用代理或网络问题，可能需要检查网络连接，或者手动下载文件再上传，如引用[4]提到的。 最后，生成相关问题，帮助用户进一步解决可能遇到的问题，比如版本冲突、权限问题，或者Harbor启动失败的情况。</think>以下是在CentOS/RHEL系统上手动安装docker-compose的完整解决方案： ### 手动安装docker-compose的两种方法 根据Harbor官方文档要求，推荐使用1.18.0以上版本的docker-compose，请按以下步骤操作： #### 方法一：二进制安装（推荐） 1. **下载最新版本** ```bash sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose ``` 如果网络受限，可先下载到本地后上传至服务器[^3][^4] 2. **设置执行权限** ```bash sudo chmod +x /usr/local/bin/docker-compose ``` 3. **创建软链接** ```bash sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose ``` 4. **验证安装** ```bash docker-compose --version # 应显示类似docker-compose version 1.29.2 ``` #### 方法二：pip安装（需Python环境） 1. **安装依赖** ```bash sudo yum install -y python3-pip libffi-devel openssl-devel ``` 2. **升级pip并安装** ```bash sudo pip3 install --upgrade pip sudo pip3 install docker-compose ``` ### 解决Harbor依赖问题 安装完成后需配置docker信任私有仓库： 1. **编辑daemon.json** ```bash sudo tee /etc/docker/daemon.json <<EOF { "insecure-registries" : ["your.harbor.domain"] } EOF ``` 2. **重启服务** ```bash sudo systemctl restart docker ``` ### 验证安装完整性 ```bash docker-compose -v # 检查版本是否>=1.18.0 docker-compose up -d # 测试基础功能 ```
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值