kubenetes知识分享提纲
k8s的背景:
容器化是微服务化的方法,而管理容器是一件麻烦的事情,k8s就是为了解决容器集群的工具。
先简单了解一下docker,docker是一个程序镜像化的脚本,我们可以将git上的代码,通过docker镜像构建脚本自动生产docker容器进程。我们可以认为docker引擎就是将代码和运行环境构建成业务进程的程序,而docker引擎缺少强大的管理机制,k8s才因此诞生。
- 对于k8s而已,所谓的镜像是k8s对容器引擎镜像的抽象(功能更加丰富的镜像),而不是具体到某一种容器的镜像(换而言之,不要认为k8s镜像就是docker image镜像,千万不要这样理解),k8s的镜像接口交CRI容器运行时接口,它的官方引擎是CRI-0
学习方法:
通过官网
https://kubernetes.io/zh/docs/home/
通过K8s的教育平台
https://www.katacoda.com/courses/kubernetes
通过网上视频介绍,1.5倍速自行翻阅。
通过博客,公众号资源,github社区,有一定基础后,自行翻阅。
https://mp.weixin.qq.com/s/Hu9ZUqR09dxl_Z_nnOSGAA
通过做笔记和实践迭代学习。
回到 https://www.katacoda.com/courses/kubernetes 云平台模拟验证自己的理解,然后做笔记。
对待k8s的立场和态度
承认对一个心事物的态度是一个变化的过程。
前期的态度:够用就好,不够用可以采用自己熟悉的技术代替。
我们首先从经验中可以知道一个规律,一个好的框架一定是具有很低的侵入性的,而不是逼着用户去用它的全家桶,这是体现了一个框架的格局和谦虚的开源态度。
我赌kubenetes是这样的一个好框架,否则就不会去用它。
我们下了赌注后,就可以基于这个前提假设,把他用于实践,甚至是去落地。
具体步骤就是,将kubenetes的内核部署到我们的集群中,然后让部分业务的部分小资源由kubenetes去管理,而且我们必须要严格遵守一个原则,不用我们的不熟悉的工具,不拿有流水或者有用户资源的业务线去赌系统的可用性,要对开源持有敬畏心理,记住“上山容易下山难”。
有了这些态度就可以开始学习k8s了。
学习k8s的动机
个人: 学习概念,了解设计,构思落地方法。
团队: 借鉴管理思想, 类比当前的系统做到知己知彼,提高团队素质,实现小规模落地。
k8s的原理
master:
api-service
controller-manager(各种高级的运维技巧都在这里实现)
scheduler
etcd
kubectl(命令行或者后台UI)
node:
kubelet
kubeproxy
pod概念,父容器Pause容器的概念,子容器容器组的概念,共享Linux资源和回收子容器进程的概念。
service-mesh 概念
探针技术的目的,是为了统一对容器引擎的管理入口。
服务编排
了解kubenetes的垂直逻辑架构
物理层,网络层,逻辑对象层,控制层,管理界面
学习kube对象的数据结构
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp1
spec:
replicas: 1
selector:
matchLabels:
app: webapp1
template:
metadata:
labels:
app: webapp1
spec:
containers:
- name: webapp1
image: katacoda/docker-http-server:latest
ports:
- containerPort: 80
学习yaml的声明
- 通用成员
- spec:selector:matchLabels 分号命令法
- 容器成员
学习几个重要的基础的kube对象
-
replicationSet 副本控制器,它可以检测并且控制副本的个数,有副本奔溃了不可用就会被替换或者移除,分类标签管理等功能。
-
deployment 是副本控制器的增强,多一个版本回滚的功能。
-
statefulSet 是一个有状态的pod,所谓的状态体现在,【pod的启动顺序】,可以使用持久卷claim,【有专用的hostname】。
-
DeamonSet 也是一种特殊的pod,它的特点就是确保每一个Node节点都有一个pod副本。通常用来部署日志采集器或者是性能监控器。
-
CronJob 一种可以定时运行的kube对象
-
Job对象通常用于运行那些仅需要执行一次的任务(例如数据库迁移,批处理脚本等等)。
-
service对象 为什么用service? 因为pod的hostname一重启就变,所以带用service对象去代理pod对象的出口。
-
几种service类型:
Cluster IP 这个是service的默认类型,创建这种类型的service,就等于声明可以通过一个分配的clusterIp去访问一组 pods ,可以通过 spec.ports.port去声明service的端口(前提是Pods的端口和spec.ports.port一样)。
【推荐】Target Ports 如果pods的端口和spec.ports.port不一样,那么我们需要用targetport去声明Pods的端口。
比如我们启动一组pods是80端口,我们需要外部用8080访问就得这样声明:
spec:
ports:
- port: 8080
targetPort: 80
selector:
app: webapp1-clusterip-targetport
NodePort 将服务暴露到Node节点的端口上,我们可以通过任何Node的内外网IP+Nodeport都能访问到这组pods。(比较特别,需要特意声明–type)
External IPs 我们可以通过如下方式暴露Pods给指定的外网IP(而不是所有node节点)
spec:
ports:
- port: 80
externalIPs:
- 172.17.0.44
selector:
app: webapp1-externalip
Load Balancer 我们可以这样的方式声明service为一个负载均衡器,这个类似看起来就是Ingress组件所支持的功能,有点像加强版的external-ips。
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: webapp1-loadbalancer
- ingress是一个external loadbalance. (spec.type为loadbalance的service也是一个external loadbalance)
apiVersion: v1
kind: Service
metadata:
name: nginx-ingress
namespace: nginx-ingress
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
- port: 443
targetPort: 443
protocol: TCP
name: https
selector:
app: nginx-ingress
externalIPs:
- 172.17.0.53
从本质上,我们可以看出,这个ingress其实也是一个serivice, 它是NodePort类型,并且指定了spec.externalIPs的对外IP和spec.port对外端口,还声明了443-tcp协议(https)与80-tcp(http)协议端口。而转发规则和权限则由nginx代理了,而路由规则的声明则需要一个 kind: Ingress 的kubenetes对象来负责了,其中ingress对象与nginx-ingress对象的IO是基于约定来实现的。
controlplane $ cat ingress-rules.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: webapp-ingress
spec:
rules:
- host: my.kubernetes.example
http:
paths:
- path: /webapp1
backend:
serviceName: webapp1-svc
servicePort: 80
- path: /webapp2
backend:
serviceName: webapp2-svc
servicePort: 80
- backend:
serviceName: webapp3-svc
servicePort: 80
-
ingress支持负载均衡,SSL,虚拟IP,ingress类似k8s集群里的一个nginx反向代理,整个集群只需要一个ingress代理即可,新增的ingress规则会自动与他绑定。
-
不管是什么副本,他们底层实现都是k8s控制器和scheduler调度器以及Pod。
学习怎么使用kubectl管理 kube对象
掌握命令 kubectl create kubectl get kubectl decribe
kubenetes的网络结构:
- 所有集群处于同一交换机器状态,然后通过证书组网形成集群,通过service暴露内网端口,通过ingress暴露外网端口,从对Pod的网络进行管理。
掌握几个高级的管理技巧:
-
监控monitor, liveness probe 存活探针(是否重启), readiness probe 准备探针(检测是否参与负载),startup probe 启动探针(处理预处理比较长的应用比如,additionallogin)
-
容忍Tolerations,则是taint的孪生概念,它是指一种不挑剔污点的Pod,我们理解为,taint和tolreations都是用来声明 pod与node亲和关系的概念。
-
密码,账号,磁盘,文件,挂载到目录还是初始化到环境变量。