(K8S实践3) Controller

3 篇文章 0 订阅

一、Kubernetes核心组件

1.核心组件概述

kubernetes主要有以下几个核心组件组成:

  • etcd:保存整个集群的状态。
  • apiserver:提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制
  • controller manager:负责维护集群的状态,比如故障检测、自动扩展、滚动更新等。
  • scheduler:负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上。
  • kubelet:负责维护容器的生命周期,同时也负责Volume(CVI)和网络(CNI)的管理。
  • Container runtime:负责镜像管理以及Pod和容器的真正运行(CRI)。
  • kube-proxy:负责为Service提供cluster内部的服务发现和负载均衡。

在这里插入图片描述
部署流程:
在这里插入图片描述

2.查看核心组件

kubelet是唯一一直作为常规系统组件来运行的组件,它把其他组件作为pod来运行

2.1查看Kubelet

master和node节点都可查看
#systemctl status kubelet
在这里插入图片描述

2.2查看其他组件

#kubectl get pod -o custom-columns=POD:metadata.name,NODE:spec.nodeName --sort-by spec.nodeName --all-namespaces
#kubectl get pod -o wide -n kube-system
在这里插入图片描述
各资源简写查看
#kubectl api-resources
在这里插入图片描述

二、Controller Manager

1.简介

在这里插入图片描述
Controller Manager由kube-contronller-manager和cloud-controller-manager组成,是Kubernetes的大脑,他通过apiserver监控维护整个集群的状态,比如故障检测、自动扩展、滚动更新等并确保集群处于预期的工作状态。
cloud-controller-manager在Kubernetes启用CloudProvider的时候才需要,用来配合云服务提供商的控制,如:Node Controller、Route Controller、Service Controller。

2.原理

Controller Manager是Kubernetes集群内部的管理控制中心,负责Kubernetes集群内的Node、Pod服务端点、服务、资源配额、命名空间、服务账号等资源的管理、自动化部署、健康监测,并对异常资源执行自动化修复,确保集群各资源始终处于预期的工作状态。比如,当某个Node意外宕机是,Controller Manager会根据资源调度策略选择集群内其他节点自动部署原来节点上的Pod副本。
Controller Manager是一个控制器集合,包含Replication Controller、Deployment Controller、RelicaSet、StatefulSet Controller、Daemon Controller、CronJob Controller、Node Controller、Resourcequota Controller、Namespace Controller、ServiceAccount Controller、Token Controller、Service Controller及Endpoint Controller等多个控制器,Controller Manager是这些控制器的核心管理者。一般来说,智能系统和自动系统通常会通过一个操纵系统来不断修正系统的状态。在Kubernetes集群中,每个控制器的核心工作原理就是:每个控制器通过API服务器来查看系统的运行状态,并尝试试着将系统状态从“现有状态”修正到“期望状态”。

三、ReplicationController

1.简介

ReplicationController会持续监控正在运行的pod列表,确保pod数量始终与其标签选择器匹配,ReplicationController由三部分组成:
label selector(标签选择器),用于确定ReplicationController作用域中有哪些pod。
replica count(副本个数),指定应该运行的pod数量。
pod template(pod模板),用于创建新的pod副本。

2.创建ReplicationController

#vim nginx-rc.yaml

apiVersion: v1
kind: ReplicationController
metadata: 
  name: nginx
spec:
  replicas: 3
  selector: 
    app: nginx
  template: 
    metadata: 
      labels: 
        app: nginx
    spec: 
      containers: 
      - name: nginx
        image: nginx

#kubectl apply -f nginx-rc.yaml
在这里插入图片描述

3.查看ReplicationController

#kubectl get rc
#kubectl describe rc nginx
在这里插入图片描述

4.扩缩容

扩缩容可以采用修改pod模板和直接命令方式
扩容
#kubectl edit rc nginx
在这里插入图片描述

5.删除pod

#kubectl delete po nginx-8qn7v
在这里插入图片描述
删除pod nginx-8qn7v,发现该pod被删除的同事k8s自动新增一个pod nginx-44jbs,这也验证了之前简介中讲的“ReplicationController会持续监控正在运行的pod列表,确保pod的数量始终与其标签选择器匹配”

6.删除ReplicationController

#kubectl delete rc nginx
在这里插入图片描述
删除ReplicationController会将其管理的pod一并删除,如果想保留pod,可以添加参数"–cascade=false"
#kubectl delete rc nginx --cascade=false
在这里插入图片描述

7.标签

7.1新增标签

#kubectl label po nginx-2477r env=prod

7.2查看标签

在这里插入图片描述

7.3更改标签

#kubectl label po nginx-2477r app=test --overwrite
更改app=nginx的标签,这将使nginx-2477r该pod不再与ReplicationController的标签选择器匹配,只剩两个匹配的pod,ReplicationController会启动一个新的pod nginx-cqrmc将总量恢复为3个。
在这里插入图片描述

四、ReplicaSet

1.简介

ReplicaSet的行为与ReplicationController完全相同,但pod选择器的表达能力更强,是新一代的ReplicationController,并且将其完全替换掉(ReplicationController最终将被弃用)

2.创建ReplicaSet

#vim httpd-rs.yaml

apiVersion: apps/v1 
kind: ReplicaSet
metadata: 
  name: httpd
spec: 
  replicas: 3
  selector: 
    matchExpressions: 
    - key: app
      operator: In
      values: 
       - httpd
  template: 
    metadata: 
      labels: 
        app: httpd
    spec: 
      containers: 
      - name: httpd
        image: httpd

ReplicaSet相对于ReplicationController的主要改进是它更具表达力的标签选择器,ReplicaSet的pod选择器的表达能力更强。
#kubectl apply -f httpd-rs.yam
在这里插入图片描述

3.查看ReplicaSet

#kubectl get rs
#kubectl describe rs httpd
在这里插入图片描述

4.删除ReplicaSet

#kubect delete rs httpd
在这里插入图片描述
同理,如需保留pod可以添加参数–cascade=false
#kubectl delete rs httpd --cascade=false
在这里插入图片描述

五、Deploymentment

1.简介

Deployment为Pod和ReplicaSet提供声明式更新。只需要在Deployment中描述想要的目标状态是什么,Deployment controller就会帮助你将Pod和ReplicaSet的实际状态改变到你的目标状态。你可以定义一个全新的Deployment,也可以创建一个新的替换旧的Deployment。
Deployment的典型应用场景 包括:
定义Deployment来创建Pod和ReplicaSet
滚动升级和回滚应用
扩容和缩容
暂停和继续Deployment

2.Deployment实践

六、DaemonSet

1.简介

与ReplicationController和ReplicaSet在Kubernetes集群上运行部署特定数量的pod不同, DaemonSet每个Node上最多只能运行一个副本,如果节点下线,DaemonSet不会在其他地方重新创建pod,当将一个新节点添加到集群中时,DaemonSet会立刻部署一个新的pod实例。如果有人无意删除了一个pod,它会从配置的pod模板中创建新的pod。

DaemonSet保证在每个Node上都运行一个容器副本,常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括:
日志收集,如fluentd,logstash等
系统监控,如Prometheus Node Exporter,collectd,New Relic agent,Gangliagmond等
系统程序,如kube-proxy,kube-dns,glusterd,ceph等
本文以日志搜索工具filebeat为例实践

2.创建DaemonSet

#vim filebeat-ds.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata: 
  name: filebeat-ds
  labels: 
    app: filebeat
spec: 
  selector: 
    matchLabels: 
      app: filebeat
  template: 
    metadata: 
      labels: 
        app: filebeat
      name: filebeat
    spec: 
      containers: 
      - name: filebeat
        image: ikubernetes/filebeat:5.6.5-alpine
        env: 
        - name: REDIS_HOST
          value: db.ilinux.io:6379
        - name: LOG_LEVEL
          value: info

#kubectl apply -f filebeat-ds.yaml
#kubectl get ds
#kubectl describe ds filebeat-ds
#kubectl get po -o wide
在这里插入图片描述

3.查看日志

#kubectl logs -f filebeat-ds-nfsjd
在这里插入图片描述

4.更新DaemontSet

#kubectl set image daemonsets filebeat-ds filebeat=ikubernetes/filebeat:5.6.6-alpine
#kubectl describe ds filebeat-ds
DaemonSet通过删除和新建方式更新image
在这里插入图片描述

5.回滚DaemonSet

5.1查询历史版本

#kubectl rollout history ds filebeate-ds
在这里插入图片描述

5.2查询某个历史版本详细信息

#kubectl rollout history ds filebeat-ds --revision=1
在这里插入图片描述

5.3回滚

#kubectl rollout undo ds filebeat-ds --to-revision=1
在这里插入图片描述

5.4查看DaemonSet状态

#kubectl rollout status ds/filebeat-ds
在这里插入图片描述

5.5删除DaemonSet

#kubectl delete ds filebeat-ds
在这里插入图片描述

七、Job

1.简介

从程序的运行形态上来区分,可以将Pod分为两类:长时运行服务(http server、daemon、mysql)和一次性任务(如并行数据计算、测试、批量处理程序等)。ReplicationController、ReplicaSet和DaemonSet创建的Pod都是长时运行服务,而Job创建的Pod都是一次性的服务。

2.创建Job

#vim job.yaml

apiVersion: batch/v1
kind: Job
metadata: 
  name: pi
spec: 
  template: 
    spec: 
      containers: 
      - name: pi
        image: perl
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

#kubectl apply -f job.yaml
在这里插入图片描述

3.查看Job

#kubectl get job
在这里插入图片描述
#kubectl get pod -o wide
查看运行结果
#kubectl logs -f pi-wh5gm
在这里插入图片描述
改job为求圆周率精确至2000位

4.并行job

vim multi-job.yaml

apiVersion: batch/v1
kind: Job
metadata: 
  name: multi-job
spec: 
  completions: 10
  parallelism: 2
  template: 
    metadata: 
      labels: 
        app: multi-job
    spec: 
      restartPolicy: OnFailure 	#设置容器失败后重启
      containers: 
      - name: busybox
        image: busybox

#kubectl apply -f multi-job.yaml
#kubectl get pod -o wide
在这里插入图片描述
每次同时运行两个job,最终运行的pod数为10

5.Cronjob

新建cronjob
#vim cronjob.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata: 
  name: hello
spec: 
  schedule: "*/1 * * * *"
  jobTemplate: 
    spec: 
      template: 
        spec: 
              containers: 
              - name: hello
                image: busybox
                args: 
                - /bin/sh
                - -c
                - date; echo Hello from the Kubernetes cluster
              restartPolicy: OnFailure   

#kubectl apply -f cronjob.yaml
在这里插入图片描述
每隔一分钟就会生成一个job
在这里插入图片描述

6.删除job

#kubectl delete job multi-job pi
#kubectl delete cronjob hello
在这里插入图片描述

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
可以使用 Kubernetes 官方提供的 NGINX Ingress Controller 进行部署,具体步骤如下: 1. 创建一个名为 `nginx-ingress` 的命名空间: ``` kubectl create namespace nginx-ingress ``` 2. 添加官方的 NGINX Ingress Controller Helm Chart 仓库: ``` helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update ``` 3. 安装 NGINX Ingress Controller: ``` helm install nginx-ingress ingress-nginx/ingress-nginx \ --namespace nginx-ingress \ --set controller.replicaCount=2 \ --set controller.nodeSelector."beta\.kubernetes\.io/os"=linux \ --set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux ``` 其中,`controller.replicaCount` 用于设置控制器的副本数量,`controller.nodeSelector."beta\.kubernetes\.io/os"=linux` 和 `defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux` 用于设置控制器和默认后端 Pod 的 NodeSelector,确保它们只会在 Linux 节点上运行。 4. 验证 NGINX Ingress Controller 是否已经成功运行: ``` kubectl get pods -n nginx-ingress ``` 如果控制器和默认后端 Pod 的状态都显示为 Running,则表示已经成功部署 NGINX Ingress Controller。 5. 部署 NGINX Ingress: ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: /$1 spec: rules: - host: example.com http: paths: - path: /example(/|$)(.*) pathType: Prefix backend: service: name: example-service port: name: http ``` 其中,`metadata.name` 用于设置 Ingress 的名称,`spec.rules.host` 用于设置 Ingress 的域名,`spec.rules.http.paths.path` 用于设置 Ingress 的路径,`spec.rules.http.paths.backend.service.name` 和 `spec.rules.http.paths.backend.service.port.name` 用于设置 Ingress 的后端服务和端口。 6. 验证 NGINX Ingress 是否已经成功部署: ``` kubectl get ingress example-ingress ``` 如果 Ingress 的状态显示为 Running,则表示已经成功部署 NGINX Ingress。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值