NameSpace
命令
查看
kubectl get ns创建
kubectl create ns hello删除
kubectl delete ns hello配置
创建
apiVersion: v1
kind: NameSpace
metadata:
name: hellokubectl apply -f hello.yaml删除
kubectl delete -f hello.yamlPod
配置
多个容器就多个 - image
apiVersion: v1
kind: Pod
metadata:
labels:
run: mynginx
name: mynginx
spec:
containers:
- image: nginx
name: mynginx命令
创建
kubectl run mynginx --image=nginx查看
kubectl get pods
kubectl get pods -n default
kubectl get pods -A可选参数
-owide 可以更详细的查看
-n 表示指定命名空间, 不穿等价于 -n default
-A 表示全部
删除
-n 指定命名空间, 用法如上
kubectl delete pod mynginx描述
kubectl describe pod mynginx描述信息中主要最下方的 Events 中会对此容器的事件进行展示. 从而可以看到关于此容器中的 所有变更
日志
只有 pod 会存在日志因此不需要 再加 pod 参数了
kubectl logs mynginxDeployment
作为 K8s 内部无状态的一类工作负载, 提供稳定的底层运算环境
与 Deployment 同级的还有 StatefulSet, DaemonSet 等等
如下图所示
概念
控制 pod, 使 pod 拥有多副本, 自愈, 扩缩容等能力
自愈
与 pod 命令行创建的不同, pod 删除后就真的删除了,
但是 deployment 删除 pods 后会马上自动创建, deployment 具备自愈能力, 不惧怕宕机或者删除
如果真的想删除则使用 删除 deployment 的命令
多副本
通过指定多副本可以动态自适应在节点中创建, 节点或进程被销毁也会自动恢复保证副本数一致
扩缩容
在多副本的基础上, 可以部署后再次对副本数量进行调整. 即扩缩容
扩缩容可以手动控制, 也可以配置后由K8s进行动态的判断处理
自愈 故障转移
当集群中的 pod 出现问题比如内存泄漏或者进程销毁等问题时, K8s 首先会尝试对 pod 进行重启, 这个过程为自愈
但是如果运行此 pod 的机器宕机了. 根本不存在重启的可能性的时候, 则 K8s 会在其他节点对此 pod 进行重启
此过程为 故障转移, 下图是故障转移的一次完整的展示, w6shc 发生故障后被迁移到 hz2xf 重新开启
滚动更新
在多副本的前提下. 如果存在 V1 到 V2 版本的更新, 则会在某一个 pod 上先进行更新, 其他保持
若更新成功, 则此pod 就可以接受 V2 版本的处理, 停止 V1 的处理, 而 V1 的流量将会交给其他未更新的 pod 处理
基于此机制再重复执行其他的 pod 里面进行 V2 的更新, 此机制保证了 V1 V2版本交替时的流量不中断更新
版本回退
版本更新后出现问题进行的回退老版本
命令
查看
kubectl get deployment可跟参数
-owide 详情展示
-n 命名空间
-A 全部命名空间
创建
kubectl create deployment mycat --image=tomac可跟参数
--image 指定镜像, 必传
--replicas 指定副本数量
删除
kubectl delete deployment mycat扩缩容
命令形式
通过命令直接控制副本数量
kubectl scale deployment mycat --replicas=5
调整配置
通过编辑配置文件也可以调整副本数量
kubectl edit deployments.apps mycat
版本更新
kubectl set image deploy/mycat nginx=nginx:1.16.1 --record大体过程如下, 先在一个上面进行更新, 然后再对其他一个一个更新
起一个新的然后再杀老的. 这样重复副本数量的4次
查看代码
[root@k8s-master ~]# clear
[root@k8s-master ~]# kubectl get pod -w
NAME READY STATUS RESTARTS AGE
mycat-75f5fc59db-75vq7 1/1 Running 0 22h
mycat-75f5fc59db-jrbhc 1/1 Running 0 22h
mycat-75f5fc59db-vbz6h 1/1 Running 0 25m
mycat-75f5fc59db-zddps 1/1 Running 0 28m
mycat-7c57d9555f-ffc2c 0/1 Pending 0 0s
mycat-7c57d9555f-ffc2c 0/1 Pending 0 0s
mycat-75f5fc59db-vbz6h 1/1 Terminating 0 25m
mycat-7c57d9555f-ffc2c 0/1 ContainerCreating 0 0s
mycat-7c57d9555f-h7h7k 0/1 Pending 0 0s
mycat-7c57d9555f-h7h7k 0/1 Pending 0 0s
mycat-7c57d9555f-h7h7k 0/1 ContainerCreating 0 0s
mycat-75f5fc59db-vbz6h 1/1 Terminating 0 25m
mycat-7c57d9555f-ffc2c 0/1 ContainerCreating 0 1s
mycat-7c57d9555f-h7h7k 0/1 ContainerCreating 0 1s
mycat-75f5fc59db-vbz6h 0/1 Terminating 0 25m
mycat-75f5fc59db-vbz6h 0/1 Terminating 0 25m
mycat-75f5fc59db-vbz6h 0/1 Terminating 0 25m
mycat-7c57d9555f-ffc2c 1/1 Running 0 33s
mycat-75f5fc59db-jrbhc 1/1 Terminating 0 22h
mycat-7c57d9555f-8qx68 0/1 Pending 0 0s
mycat-7c57d9555f-8qx68 0/1 Pending 0 0s
mycat-7c57d9555f-8qx68 0/1 ContainerCreating 0 0s
mycat-75f5fc59db-jrbhc 1/1 Terminating 0 22h
mycat-75f5fc59db-jrbhc 0/1 Terminating 0 22h
mycat-7c57d9555f-8qx68 0/1 ContainerCreating 0 1s
mycat-75f5fc59db-jrbhc 0/1 Terminating 0 22h
mycat-75f5fc59db-jrbhc 0/1 Terminating 0 22h
mycat-7c57d9555f-h7h7k 1/1 Running 0 48s
mycat-75f5fc59db-zddps 1/1 Terminating 0 29m
mycat-7c57d9555f-2tv2v 0/1 Pending 0 0s
mycat-7c57d9555f-2tv2v 0/1 Pending 0 0s
mycat-7c57d9555f-2tv2v 0/1 ContainerCreating 0 0s
mycat-75f5fc59db-zddps 1/1 Terminating 0 29m
mycat-7c57d9555f-2tv2v 0/1 ContainerCreating 0 1s
mycat-75f5fc59db-zddps 0/1 Terminating 0 29m
mycat-75f5fc59db-zddps 0/1 Terminating 0 29m
mycat-75f5fc59db-zddps 0/1 Terminating 0 29m
mycat-7c57d9555f-8qx68 1/1 Running 0 31s
mycat-75f5fc59db-75vq7 1/1 Terminating 0 22h
mycat-75f5fc59db-75vq7 1/1 Terminating 0 22h
mycat-75f5fc59db-75vq7 0/1 Terminating 0 22h
mycat-75f5fc59db-75vq7 0/1 Terminating 0 22h
mycat-75f5fc59db-75vq7 0/1 Terminating 0 22h
mycat-7c57d9555f-2tv2v 1/1 Running 0 31s
^C[root@k8s-master ~]#
[root@k8s-master ~]# kubectl get pod -w
NAME READY STATUS RESTARTS AGE
mycat-7c57d9555f-2tv2v 1/1 Running 0 107s
mycat-7c57d9555f-8qx68 1/1 Running 0 2m2s
mycat-7c57d9555f-ffc2c 1/1 Running 0 2m35s
mycat-7c57d9555f-h7h7k 1/1 Running 0 2m35s
版本回退
查看版本
需要回退前先看下之前的版本记录
kubectl rollout history deployment mycat
回退命令
--to-revision 指定要回到的版本即可, 回退本质上也是一次滚动更新
kubectl rollout undo deployment mycat --to-revision=1
通过查看 -oyaml 可以看到镜像返回到了1的版本记录
Service
概念
service 是将一组 pod 公开为网络服务的抽象方法, 并且具备对 pod 服务发现以及负载均衡的能力
命令
创建/暴露
--port 暴露端口
--target-port 目标端口
kubectl expose deployment mycat --port=8000 --target-port=80--type 暴露类型, 默认取值 ClusterIP 集群IP
此时这个 ip 只是集群内部有效的, ip 在子节点的机器上是可以用的
同时服务也会产生一个域名, 域名的命名规则是 label.namespace.svc
在 pod 内部使用域名进行对接也是没问题的, 但是此域名在集群内的机器上是不行的, 只能在 pod 内
--type 取值为 NodePort 时为 节点IP
此时会默认在 30000 - 32767 之间随机一个端口进行暴露, 此端口会暴露在所有的节点机器上
通过访问任意机器的 公网IP +此端口 既可以访问服务, 此场景下是兼容 ClusterIP 的, 依旧保有集群内的访问能力以及 pod 内的 域名机制
查看
kubectl get service
# 简写
kubectl get svc 
service 里面的 pod 会被打上标签
删除
kubectl delete service mycatIngress
概念
Ingress 作为集群的唯一入口管理集群的所有流量
即service 的统一网关入口
安装
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.47.0/deploy/static/provider/baremetal/deploy.yaml
# images 换成
registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/ingress-nginx-controller:v0.46.0
kubectl apply -f ingress.yaml安装成功后前面两个就是 completed , 最后一个是 running 即可
可以看到 ingress 是以 NodePort 的方式暴露出来. 然后用 30685 和 30147 来分别接收 80 和 443 的流量, 分别是 http 和 https 的流量
验证
此时可以验证下访问任意节点的 ip+端口, 可以看到已经实现了服务
K8s 网络模型
架构图
由 pod / service / ingress 进行三层划分,
pod 运行业务, service 提供服务. ingress 统一入口, LB 作为负载
Ingress 实战
环境搭建
配置
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-server
spec:
replicas: 2
selector:
matchLabels:
app: hello-server
template:
metadata:
labels:
app: hello-server
spec:
containers:
- name: hello-server
image: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/hello-server
ports:
- containerPort: 9000
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx-demo
name: nginx-demo
spec:
replicas: 2
selector:
matchLabels:
app: nginx-demo
template:
metadata:
labels:
app: nginx-demo
spec:
containers:
- image: nginx
name: nginx
---
apiVersion: v1
kind: Service
metadata:
labels:
app: nginx-demo
name: nginx-demo
spec:
selector:
app: nginx-demo
ports:
- port: 8000
protocol: TCP
targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
labels:
app: hello-server
name: hello-server
spec:
selector:
app: hello-server
ports:
- port: 8000
protocol: TCP
targetPort: 9000验证
起来 4个 pod
node 1 的地址是 192.168.109.95 / 96
node 2 的地址是 192.168.140.110 / 111
可以测试下效果
两个节点上的 hello-world
两个节点上的 ng-demo
域名访问
配置
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-host-bar
spec:
ingressClassName: nginx
rules:
- host: "hello.yangtuo.com"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: hello-server
port:
number: 8000
- host: "demo.yangtuo.com"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: nginx-demo
port:
number: 8000逻辑
如图实现
hello.yangtuo.com:31401 访问 hello-server
demo.yangtuo.com:31401 访问 nginx-demo
生效
注意这里的 ADDRESS 是ingress 转发的地址, 下面就要用到
测试
在 master 上加下这两个新配置的域名
然后测试这两个域名, 可见以及生效了
在宿主机上测试
对 宿主机的 host 进行配置 路径在 C:\Windows\System32\drivers\etc
效果也是一样的
修改配置
命令
kubectl edit ingress ingress-host-bar直接修改后即可生效, 操作方式和 svc or pod or deploy 类似
示例
如修改 path 这样就必须 hellow.yangtuo.com/hi 才可以访问到 hello-server 服务
验证
PS :
这里倘若对 demo-nginx 的 path 进行操作从 / 改成 /xxx , 将会返回 404
是因为通过了 ingress 层后, 将请求转给了具体的服务(demo-nginx), 而服务部没有对 xxx 的处理, 才会返回 404
与 ingress 层返回的 404 是不同的, 具体的区别是内部返回的会带 nginx 的版本号
而 ingress 层返回的是不会带版本号的
为避免这个问题则可以使用路径重写功能如下
官方文档
更多想起的操作参考 官方文档 这里这里
更多的高级功能就在注解里面找就可以了, 都有详细的实例和文档, 比如路径重写, 限流等
路径重写
地址 这里这里
举例效果
这里的把
官方示例
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
# 就是家这里两行
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
name: rewrite
namespace: default
spec:
ingressClassName: nginx
rules:
- host: rewrite.bar.com
http:
paths:
# 这里就是要覆盖掉的地方, something 替换你想去掉的东西即可
- path: /something(/|$)(.*)
pathType: Prefix
backend:
service:
name: http-svc
port:
number: 80