Kuberneters总结

最新推荐文章于 2024-09-08 22:00:26 发布

GhostSquad

最新推荐文章于 2024-09-08 22:00:26 发布

阅读量332

点赞数

分类专栏： K8S+Docker 文章标签：容器

本文链接：https://blog.csdn.net/niupeng1234a/article/details/103749492

版权

K8S+Docker 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Kuberneters

安装：

	kubeadm
	二进制安装

基本概念

Pod

Deleyment

CronJob

Service

Namespace

Resources

   resources:
    	request:                               //容器需要大小
    		cpu: 100m                          //0.1H
    		memory: 100Mi
    	limit:                                    //最大限制大小
    		cpu: 100m
    		memory: 100Mi

知识点：驱逐

Soft Eviction Thresholds
软驱逐机制表示，当node的内存/磁盘空间达到一定的阈值后，我要观察一段时间，如果改善到低于阈值就不进行驱逐，若这段时间一直高于阈值就进行驱逐。
Hard Eviction Thresholds
强制驱逐机制则简单的多，一旦达到阈值，立刻把pod从本地kill
Pod eviction
当资源使用情况触发了驱逐条件时，kubelet会启动一个任务去轮流停止运行中的pod，直到资源使用状况恢复到阈值以下。以硬驱逐为例，整体流程是：

每隔一段时间从cadvisor中获取资源使用情况，发现触发了阈值；
从运行中的pod里找到QoS策略最开放的一个，比如策略为bestEffort的一个pod（即便这个pod没有吃多少内存，大部分内存是另一个策略为burstable，但内存使用率也很高的pod），kubelet停止该pod对应的所有容器，然后将pod状态更新为Failed。如果该pod长时间没有被成功kill掉，kubelet会再找一个pod进行驱逐。
检查内存用量是否恢复到阈值以下，如果没有，则重复第二步（这里就要干掉那个罪魁祸首了）。一直到内存使用情况恢复到阈值以下为止。

Lable

livenessProbe 健康检查

基于sh

        livenessProbe:
			exec:
				common:
					- bin/bash
					- -c 
					-  ps -ef | grep java | grep -v grep
			initialDeloySeconds: 20
			periodSeconds: 20
			failureThreshold: 2
			successThreshold: 1
			timeoutSeconds: 5

基于http

        livenessProbe:
			httpGet:
				path: /test/index.html
				port: 8080
				scheme: HTTP
			initialDeloySeconds: 20
			periodSeconds: 20
			failureThreshold: 2
			successThreshold: 1
			timeoutSeconds: 5

基于tcp

        livenessProbe:
			tcpSocket:
				port: 8080
			initialDeloySeconds: 20
			periodSeconds: 20
			failureThreshold: 2
			successThreshold: 1
			timeoutSeconds: 5
	    readinessProbe:   // 健康检查通过后，再加入sevice提供服务
	    	tcpSocket:
				port: 8080
			initialDeloySeconds: 20
			periodSeconds: 20
			failureThreshold: 2
			successThreshold: 1
			timeoutSeconds: 5

Schedular

阶段

预选策略
优选策略

策略

亲和性

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - az1
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0

两种类型：

requiredDuringSchedulingIgnoredDuringExecution: hard，严格执行，满足规则调度，否则不调度，在预选阶段执行，所以违反hard约定一定不会调度到
preferredDuringSchedulingIgnoredDuringExecution：soft，尽力执行，优先满足规则调度，在优选阶段执行，
后缀IgnoredDuringExecution表示如果labels发生改变，使得原本运行的pod不在满足规则，那么这个pod将忽视这个改变，继续运行。
requiredDuringSchedulingRequiredDuringExecution：未实现，与之前类似，只是后缀不同，代表如果labels发生改变，kubelet将驱逐不满足规则的pod
Note: 支持的operator操作： In, NotIn, Exists, DoesNotExist, Gt, Lt. 其中，NotIn and DoesNotExist用于实现反亲和性。
Note: weight范围1-100。这个涉及调度器的优选打分过程，每个node的评分都会加上这个weight，最后bind最高的node。

限制

同时指定nodeSelector and nodeAffinity，pod必须都满足
nodeAffinity有多个nodeSelectorTerms ，pod只需满足一个
nodeSelectorTerms多个matchExpressions ，pod必须都满足
由于IgnoredDuringExecution，所以改变labels不会影响已经运行pod

反亲和性
污点（taints）和容忍（tolerations）

NoSchedule: 一定不能被调度
PreferNoSchedule: 尽量不要调度
NoExecute: 不仅不会调度, 还会驱逐Node上已有的Pod
kubectl taint nodes node1 key1=value1:NoSchedule

部署策略

重建(recreate)：停止旧版本部署新版本

apiVersion: v1
kind: Service
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  type: NodePort
  ports:
  - name: http
    port: 80
    targetPort: http
  selector:
    app: my-app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
        version: v1.0.0
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9101"
    spec:
      containers:
      - name: my-app
        image: containersol/k8s-deployment-strategies
        ports:
        - name: http
          containerPort: 8080
        - name: probe
          containerPort: 8086
        env:
        - name: VERSION
          value: v1.0.0
        livenessProbe:
          httpGet:
            path: /live
            port: probe
          initialDelaySeconds: 5
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: probe
          periodSeconds: 5

滚动更新(rolling-update)：一个接一个地以滚动更新方式发布新版本

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 10
  # maxUnavailable设置为0可以完全确保在滚动更新期间服务不受影响，还可以使用百分比的值来进行设置。
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
        version: v2.0.0
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9101"
    spec:
      containers:
      - name: my-app
        image: containersol/k8s-deployment-strategies
        ports:
        - name: http
          containerPort: 8080
        - name: probe
          containerPort: 8086
        env:
        - name: VERSION
          value: v2.0.0
        livenessProbe:
          httpGet:
            path: /live
            port: probe
          initialDelaySeconds: 5
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: probe
          # 初始延迟设置高点可以更好地观察滚动更新过程
          initialDelaySeconds: 15
          periodSeconds: 5

蓝绿(blue/green)：新版本与旧版本一起存在，然后切换流量

蓝/绿发布是版本2 与版本1 一起发布，然后流量切换到版本2，也称为红/黑部署。蓝/绿发布与滚动更新不同，版本2(绿) 与版本1(蓝)一起部署，在测试新版本满足要求后，然后更新更新 Kubernetes 中扮演负载均衡器角色的 Service 对象，通过替换 label selector 中的版本标签来将流量发送到新版本。

金丝雀(canary)：将新版本面向一部分用户发布，然后继续全量发布

金丝雀部署是让部分用户访问到新版本应用，在 Kubernetes 中，可以使用两个具有相同 Pod 标签的 Deployment 来实现金丝雀部署。新版本的副本和旧版本的一起发布。在一段时间后如果没有检测到错误，则可以扩展新版本的副本数量并删除旧版本的应用。
如果需要按照具体的百分比来进行金丝雀发布，需要尽可能的启动多的 Pod 副本，这样计算流量百分比的时候才方便，比如，如果你想将 1% 的流量发送到版本 B，那么我们就需要有一个运行版本 B 的 Pod 和 99 个运行版本 A 的 Pod，当然如果你对具体的控制策略不在意的话也就无所谓了，如果你需要更精确的控制策略，建议使用服务网格（如 Istio），它们可以更好地控制流量。
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

A/B测(a/b testing)：以精确的方式（HTTP 头、cookie、权重等）向部分用户发布新版本。A/B测实际上是一种基于数据统计做出业务决策的技术。在 Kubernetes 中并不原生支持，需要额外的一些高级组件来完成改设置（比如Istio、Linkerd、Traefik、或者自定义 Nginx/Haproxy 等）。

A/B 测试实际上是一种基于统计信息而非部署策略来制定业务决策的技术，与业务结合非常紧密。但是它们也是相关的，也可以使用金丝雀发布来实现。
除了基于权重在版本之间进行流量控制之外，A/B 测试还可以基于一些其他参数（比如 Cookie、User Agent、地区等等）来精确定位给定的用户群，该技术广泛用于测试一些功能特性的效果，然后按照效果来进行确定。
我们经常可以在今日头条的客户端中就会发现有大量的 A/B 测试，同一个地区的用户看到的客户端有很大不同。
要使用这些细粒度的控制，仍然还是建议使用 Istio，可以根据权重或 HTTP 头-等来动态请求路由控制流量转发。
详情：https://www.jianshu.com/p/71e14c31cb82