架构
swarm 对比
docker swarm 的架构
K8s 的架构本质类似于 swarm, 只是节点角色命名不同, k8s 使用 master 和 node 进行区分
而且 master 上提供了便携的 api 了可以进行访问
master
上 apiserver 提供外部接口支持. scheduler 调度器进行一系列算法的决策比如容器的建立具体在哪个位置等等
controller 控制器可以做扩展或者负载均衡等等, etcd 主要做状态配置等
node
对于普通的 node 节点里面有个很重要的概念 pod
pod 是一系列具有相同的 namespace 的 container 组合
最上面的 可选插件, 比如 DNS, UI, etc 等
最下面下面的 4个紫色块
- docker 用于提供容器化的技术支持
- kubelet 是作用于master 对 node 控制的相关操作
- kube-proxy 服务的发现, 负载均衡, 以及网络的代理由此部分完成
- Fluentd 日志的采集整理存储查询等
安装
Minikube
Minikube 很方便的创建一个单节点的 k8s, 注意需要 安装 kubectl 以及一个 虚拟机, 推荐 v-box
安装好之后可以使用 version 进行验证, 然后 启动命令
minkube start
进入虚拟机中
minkube ssh
kubectl
Minikube 创建的 虚机会将 kubectl 的上下文处理好. 可以通过
kubectl config view
进行查看当前的上下文信息
kubectl config get-contexts
kubectl cluster-info
K8s 对象模型
k8s 集群创建是由记录了集群期望状态的yml文件所定义, 文件内的内容可以抽象为上图对k8s 对象模型
Pod
定义
pod 作为 k8s 的最小的调度单位, 因为已经是最小单位了, 是不会对容器进行基本操作的
一个 pod 可以包含多个 container, 在同一个 pod 的因为同享空间, 因此彼此是可以直接使用 localhost 进行通信的
创建 pod
k8s 的创建定义也是类似 docker-compose 的形式以一个 yml 文件作为基础来构建 k8s 的集群
这里 pod 的定义如下图 kind 进行定义 Pod
spec 中的 containers 进行定义 服务
通过文件创建 pod
kubectl create -f xxxx
删除当前存在的 pod
kubectl create -f xxxx
查看当前的 pod 状态列表
kubectl get pods
指定参数 -o wide 可以看到具体的 container 的详细信息
进入 pod 内部
kubectl exec -it xxxx
对于一个只含有一个 container 的pod 可以通过此命令直接进入
但是如果 pod 存在多个 container , 则需要使用 -c 进行指定具体要进入的 container
如果不指定, 则默认进入第一个
查看 pod 的具体描述信息
kubectl describe pods xxxx
pod 网络端口转发
kubectl port-flowward nginx 8080:80
但是此方式会保持会话, 将 nginx 的 80 映射到 minikube 虚拟机的 8080端口
ReplicaSet
定义创建
在 yml 文件中设定 kind 为 ReplicaSet 即可启动 ReplicaSet
spec 中的 replicas 设定为 3 可以横向扩展 3个
注意版本. v1 的版本中不支持 ReplicaSet , 可以使用 ReplicationController 进行平替
这两个也存在一定的区别
这里如果要使用 ReplicaSet 的话, 调整 apiVersion 为 apps/v1 即可
查看 replicas 的启动状态
kubectl get rc
验证 replicas 的维持
当删除某一个 pod 的时候可以看到如果是以 replicasset 方式启动的服务会自动再次重新创建
replicas 的扩展
设定的数值可升可降
kubectl scale rc nginx --replicas=2
可以看出 replicas 是比 pod 有更好的稳定性
Deployments
定义创建
声明描述了一个可期望的状态, 这样 使用 deployment 努力让这个期望进行实现
通过 deployment 创建的 pod 是不可以进行手动删除的,
只能通过 deployment 进行操作
创建依旧是 kubectl create -f
查看 deployment 状态
可以看待 deployment 创建的名字后面, 在 replicas 中多拼接了 一段 随机数, 然后在 pods 里面再追加了一段进行区分
deployment 的升级
kubectl set image deployment nginx-deployment nginx-nginx:1.13
前后交替的版本历史也会在 这里体现
kubectl rollout history deployment nginx-deployment
通过 undo 可以让本次升级失效, 从而实现回滚, 而回滚后的了历史因为长度的限制把第一次的记录冲掉了
deployment 端口暴露 (创建服务)
kubectl dxpose deployment nginx-deployment --type=NodePort
调整 deployment 配置
通过 deployment 创建的 pods 是无法编辑删除的. 只能通过命令
kubectl edit deploumeng service-test
此命令可以直接打开指定的 deployment 的 yml 文件
在这里编辑后将会立即生效, 服务会很短暂的 down 掉后马上以更新后的内容开启
比如删除 pod 或者更改版本之类的
Services
不要直接使用和管理 Pods, 但是不可避免的
创建 Services
ClusterIP 可以允许集群内的任何节点都可以对此进行访问, 但是不允许外界访问
NodePort 是绑定在某一个节点上允许此节点可以被外部进行访问
LoadBalancer 一般是由云服务商进行提供, 通过此进行内部的services 进行访问
以上都是基于 IP 进行的. 如果希望基于DNS 则需要相关的插件
创建的命令
kubectl expose nginx-pod
--type 指定要创建的类型, 未指定默认是 ClusterIP 的类型. 只允许内部访问
文件形式创建
用文件的形式可以对当前系统存在的 pod 进行升级为一个 services
比如这个 pod
services 的 yml 文件
文件中的 app 可以通过 --show-lables 进行查看
注意绑定端口的范围
查看 Services
kubectl get svc
---------------------orz 前方施工中