Kubernetes 概念入门
本文主要归纳了K8s入门的一些必须熟知的概念,具体的还是需要自己去看相关文档学习,建议过一遍本文了解概念后深入学习。
整体架构
在一个K8s应用中,简单来讲我们主要需要以下:
- Container: 基本容器,可以是Docker,甚至也可以是其他容器!
- Pod: K8s基本单元,简单理解为就是一个管理着多容器的集装箱,能做到对多个Container的管理
- Deployment: 对Pod进行管理
- Service: 集群内虚拟出来的一个网络层,通过修改路由实现,实际上网络并不存在这一层
- Ingress: 集群外访问的网络层
Kubernetes 对象
该对象包含了我们对该应用正常运行时的预期状态和现在状态。
即对象规约(Spec)与状态(Status)
如同 Deployment 对象,通过指定spec
来设置其预期状态,K8S便会自动化的去更新 status
到我们的预期状态:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec: # Deployment 的预期状态
selector:
matchLabels:
app: nginx
replicas: 2 # tells deployment to run 2 pods matching the template
template: # Pod 的模板?
metadata:
labels:
app: nginx
spec: # Pod 的预期状态
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
Kubernetes 对象管理方式
K8s的运行需要Deployment等对象 如何去新增修改删除K8s对象等都需要一个管理API来操作
如上述是通过YAML文件来管理K8s对象的,但同时还可以通过其他方式来管理Kubernetes 对象
Shell命令
简单的部署通过 kubectl
来管理即可
kubectl run nginx --image nginx
kubectl create deployment nginx --image nginx
命令式对象配置
一般性的部署可以通过配置YAML或JSON文件来实现
kubectl create -f nginx.yaml # 新增
kubectl delete -f nginx.yaml -f redis.yaml # 删除
kubectl replace -f nginx.yaml # 更新
声明式对象配置
使用声明式对象配置时,用户对本地存储的对象配置文件进行操作,但是用户未定义要对该文件执行的操作。
kubectl
会自动检测每个文件的创建、更新和删除操作。这使得配置可以在目录上工作,根据目录中配置文件对不同的对象执行不同的操作。
处理 configs
目录中的所有对象配置文件,创建并更新活动对象。可以首先使用 diff
子命令查看将要进行的更改,然后在进行应用:
kubectl diff -f configs/
kubectl apply -f configs/
递归处理目录:
kubectl diff -R -f configs/
kubectl apply -R -f configs/
架构
节点
Node: 一个虚拟机或者物理机器,主要用于运行Pods
每个节点都包含:
- kubelet: 节点代理,相当于一个控制单元,和ApiServer通信保证容器运行
- container-runtimes: 主要是运行的相关环境如Docker
- kube-proxy: 网络代理
注册方式:
- 节点上的
kubelet
向控制面执行自注册: 首选模式。 - 你,或者别的什么人,手动添加一个 Node 对象。
ApiServer通信
ApiServer和集群的通信方式中,集群和ApiServer通信通常采用的是HTTPS链接通信,并通过令牌等身份认证方式保证两端安全通信。
而对于ApiServer到集群的通信一般有以下方案:
ApiServer到 kubelet
从 ApiServer 到 kubelet 的连接用于:
- 获取 Pod 日志
- 挂接(通过 kubectl)到运行中的 Pod
- 提供 kubelet 的端口转发功能。
Apiserver 到节点、Pod 和服务
从 Apiserver 到节点、Pod 或服务的连接默认为纯 HTTP 方式,因此既没有认证,也没有加密。 这些连接可通过给 API URL 中的节点、Pod 或服务名称添加前缀 https:
来运行在安全的 HTTPS 连接上。 不过这些连接既不会验证 HTTPS 末端提供的证书,也不会提供客户端证书。 因此,虽然连接是加密的,仍无法提供任何完整性保证。 这些连接 目前还不能安全地 在非受信网络或公共网络上运行。
Konnectivity 服务
作为 SSH 隧道的替代方案,Konnectivity 服务提供 TCP 层的代理,以便支持从控制面到集群的通信。 Konnectivity 服务包含两个部分:Konnectivity 服务器和 Konnectivity 代理,分别运行在 控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。 启用 Konnectivity 服务之后,所有控制面到节点的通信都通过这些连接传输。
控制器
控制器通过监控集群 的公共状态,并致力于将当前状态转变为期望的状态。
每个控制器(Job、Deployment等)都致力于去实现期望状态,他们分管不同的集群状态,通过使用某类资源将另一类资源变为期望状态。