Kubernetes学习笔记(更新中。。。。)

Kubernetes

每个微服务通过Docker进行发布,随着业务的发展,系统中遍布着各种各样的容器。于是容器的资源调度,部署运行,扩容缩容就是我们需要面临的问题。

基于 Kubernetes 作为容器集群的管理平台被广泛应用

Kubernetes架构

Kubernetes是用来管理容器集群的平台。但它不是直接来管理容器,而是把容器放在pod中,通过管理pod来管间接管理容器。

在这里插入图片描述

Master

我们通过 Master 对每个节点 Node 发送命令。简单来说,Master 就是管理者,Node 就是被管理者。

Node

Node可以是一台物理机或者是虚拟机。在Node上面可以运行多个Pod,Pod是Kubernetes管理的最小单位,同时每个pod可以包含多个容器。

Kubectl

通常我们都是通过 kubectl 对 Kubernetes 下命令的,它通过 APIServer 去调用各个进程来完成对 Node 的部署和控制。

API Server
  • APIServer 的核心功能是对核心对象(例如:Pod,Service,RC)的增删改查操作,同时也是集群内模块之间数据交换的枢纽。
  • 它包括了常用的 API,访问(权限)控制,注册,信息存储(etcd)等功能。在它的下面我们可以看到 Scheduler,它将待调度的 Pod 绑定到 Node 上,并将绑定信息写入 etcd 中。
  • etcd 包含在 APIServer 中,用来存储资源信息
Controller Manager

Kubenetes是一套自动化运行的系统,那么就需要有一套管理规则来控制这套系统。Controller Manager 就是这个管理者,或者说是控制者。它包括 8 个 Controller,分别对应着副本,节点,资源,命名空间,服务等等。

Schedular

将待调度的pod绑定到Node上,并将绑定信息写入etcd。

kubelet

kubelet 用于处理 Master 下发到 Node 的任务(即 Scheduler 的调度任务),同时管理 Pod 及 Pod 中的容器。

服务部署

指令部署
kubectl run my-app --image=hub.kaikeba.com/library/myapp:v1 --port=80
yaml文件部署
kubectl create -f xxx.yml

deployment

apiVersion: apps/v1   # 1.9.0 之前的版本使用 apps/v1beta2,可通过命令kubectl api-versions 查看
kind: Deployment 	#指定创建资源的角色/类型
metadata: 	 #资源的元数据/属性
  name: nginx-deployment	#资源的名字,在同一个namespace中必须唯一
spec:
  replicas: 2 	 #副本数量2
  selector:      #定义标签选择器
    matchLabels:
      app: web-server
  template: 	 #这里Pod的定义
    metadata:
      labels: 	 #Pod的label
        app: web-server
    spec:		 # 指定该资源的内容  
      containers:  
      - name: nginx 	 #容器的名字  
        image: nginx:1.12.1  #容器的镜像地址    
        ports:  
        - containerPort: 80  #容器对外的端口

pod

apiVersion: v1
kind: Pod  
metadata:  
  name: pod-redis
  labels:
    name: redis
spec: 
  containers:
  - name: pod-redis
    image: docker.io/redis  
    ports:
    - containerPort: 80	#容器对外的端口

service

apiVersion: v1  
kind: Service  # 指明资源类型是 service
metadata:  
  name: httpd-svc # service 的名字是 httpd-svc
  labels:  
    name: httpd-svc 
spec:  
  ports:  # 将 service 8080 端口映射到 pod 的 80 端口,使用 TCP 协议
  - port: 8080
    targetPort: 80  
    protocol: TCP  
  selector:  
    run: httpd # 指明哪些 label 的 pod 作为 service 的后端

API server

APIServer 的架构从上到下分为四层:

  • **API 层:**主要以 REST 方式提供各种 API 接口,针对 Kubernetes 资源对象的 CRUD 和 Watch 等主要 API,还有健康检查、UI、日志、性能指标等运维监控相关的 API。
  • **访问控制层:**负责身份鉴权,核准用户对资源的访问权限,设置访问逻辑(Admission Control)。
  • **注册表层:**选择要访问的资源对象。PS:Kubernetes 把所有资源对象都保存在注册表(Registry)中,例如:Pod,Service,Deployment 等等。
  • **etcd 数据库:**保存创建副本的信息。用来持久化 Kubernetes 资源对象的 Key-Value 数据库。

在这里插入图片描述

Controller Manager

Kubernetes 需要管理集群中的不同资源,所以针对不同的资源要建立不同的 Controller。

每个 Controller 通过监听机制获取 APIServer 中的事件(消息),它们通过 API Server 提供的(List-Watch)接口监控集群中的资源,并且调整资源的状态。

可以把它想象成一个尽职的管理者,随时管理和调整资源。比如 MySQL 所在的 Node 意外宕机了,Controller Manager 中的 Node Controller 会及时发现故障,并执行修复流程。

在部署了成百上千微服务的系统中,这个功能极大地协助了运维人员。从此可以看出,Controller Manager 是 Kubernetes 资源的管理者,是运维自动化的核心。

它分为 8 个 Controller,上面我们介绍了 Replication Controller,这里我们把其他几个都列出来,就不展开描述了。

img

Controller Manager 中不同的 Controller 负责对不同资源的监控和管理

Scheduler 与 kubelet

在这里插入图片描述

Scheduler 的作用是,将待调度的 Pod 按照算法和策略绑定到 Node 上,同时将信息保存在 etcd 中。

如果把 Scheduler 比作调度室,那么这三件事就是它需要关注的,待调度的 Pod、可用的 Node,调度算法和策略。

简单地说,就是通过调度算法/策略把 Pod 放到合适的 Node 中去。此时 Node 上的 kubelet 通过 APIServer 监听到 Scheduler 产生的 Pod 绑定事件,然后通过 Pod 的描述装载镜像文件,并且启动容器。

也就是说 Scheduler 负责思考,Pod 放在哪个 Node,然后将决策告诉 kubelet,kubelet 完成 Pod 在 Node 的加载工作。

说白了,Scheduler 是 boss,kubelet 是干活的工人,他们都通过 APIServer 进行信息交换。

img

Scheduler 与 kubelet 协同工作图

Service

服务部署使用K8s来进行部署,如何实现集群 ?

复制多个pod实现负载均衡即可

多个pod之间如何进行访问?

k8s提供了一个service资源对象,实现多个pod之间的请求转发。

在 Kubernetes 中的 Service 定义了一个服务的访问入口地址(IP+Port)。Pod 中的应用通过这个地址访问一个或者一组 Pod 副本。

Service 与后端 Pod 副本集群之间是通过 Label Selector 来实现连接的。Service 所访问的这一组 Pod 都会有同样的 Label,通过这样的方法知道这些 Pod 属于同一个组。(一般一组业务(pod)对应一个service

在这里插入图片描述
通过 kubectl get svc 查看service资源对象

在这里插入图片描述

这里的cluster-ip是由kubernetes自动分配的。当一个pod需要访问其他的pod的时候就需要通过Service的Cluster-ip和Port。也就是说CLuster-ip和Pod是Kubernetes集群的内部地址,是提供给集群内的Pod之间访问使用的,外部系统是无法通过这个Cluster-ip来访问Kubernetes中的应用。

service如何实现对pod的负载均衡?

通过iptables ,默认是轮询。

KubeProxy

在Kubenetes集群上的每个Node上都会运行一个Kube-proxy服务进程,我们可以把这个进程看作Service的负载均衡器,其核心功能是将到Service的请求转发到后端的多个Pod上。

此外,Service 的 Cluster-IP 与 NodePort 是 kube-proxy 服务通过 iptables 的 NAT 转换实现的。kube-proxy 在运行过程中动态创建与 Service 相关的 iptables 规则。

由于 iptables 机制针对的是本地的 kube-proxy 端口,所以在每个 Node 上都要运行 kube-proxy 组件。
在这里插入图片描述

Ingress

在这里插入图片描述

Ingress 是一个反向代理服务,底层就是Nginx,是Kubernetes对nginx做了扩展开发;因此Ingress具有动态配置的的能力;

Ingress作用是对后端ServiceVIP提供反向代理服务;使得对外用户只有一个访问的入口,所有请求都必须经过INgress进行转发,转发给后端Service,然后由Service把请求转发给POD服务。

All in all

Kubernetes是用来管理容器集群的,Master作为管理者,包括API server ,Scheduler、Controller Manager。

Node作为副本部署的载体,包含多个Pod,每个Pod又包含多个容器(container)。用户通过kubectl 给Master中的APIServer下部署命令。

命令主体是以“.yaml”结尾的配置文件,包含副本的类型,副本个数,名称,端口,模版等信息。

APIServer 接受到请求以后,会分别进行以下操作:权限验证(包括特殊控制),取出需要创建的资源,保存副本信息到etcd。

APIServer 和 Controller Manager,Scheduler 以及 kubelete 之间通过 List-Watch 方式通信(事件发送与监听)。

Controller Manager 通过 etcd 获取需要创建资源的副本数,交由 Scheduler 进行策略分析。

最后 kubelet 负责最终的 Pod 创建和容器加载。部署好容器以后,通过 Service 进行访问,通过 cAdvisor 监控资源。

常用指令

查看某分支下的pod

kubectl get pod -n dev-core

查看pod内某个容器的日志

kubectl logs <容器名> -n dev-core

查看分支下的ingress

kubectl get ingress -n dev-core

部署指令

kubectl run myapp –image=镜像地址 –port=80 容器端口

以yaml文件部署

kubectl create -f xxx.yaml

查询资源对象:

  • kubectl get pod
  • kubectl get deployment
  • kubectl get rs
  • kubectl get pod -o wide

进入dev-core中pod的容器内部(前提是该pod中只有一个容器)

 kubectl exec -it nvhl-pcis-elasticsearch-impl-546f4d649c-rpwsj-n dev-core -- /bin/bash

查看资源对象描述信息

kubectl describe pod/ContainerName  -n dev-core
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值