1.k8s中的资源
1.1检查网络环境
kubectl -n kube-flannel get pods
kubectl -n kube-flannel get pods -o wide、
1.2资源管理介绍
1.在k8s中，所有的内容都抽象为资源，用户需要通过管理资源来管理k8s（ kubectl api-resources 查看k8s中所有的资源）
2.k8s的本质就是一个集群系统，用户可以在集群中部署各种服务
3.所谓的部署服务，其实就是在kubernetes集群中运行一个个容器，并将指定的程序跑在容器中
4.kubernetes的最小管理单元式pod而不是容器，只能将容器放在pod中
5.kubernetes一般不会直接管理pod而是通过控制器来管理pod
6.pod中服务的访问是通过kubernetes提供的service（微服务暴露端口）资源来实现
7.pod中程序的数据需要持久化是由kubernetes提供的各种存储来实现的
1.3资源管理方式
1.命令式（操作完就没了，不能审计与跟踪）
kubectl run nginx-pod --image=nginx:latest --port=80
2.文件式(不能做更新，只能建立)
kubectl cerate -f nginx-pod.yaml
3.声明式
kubectl apply -f nginx-pod.yaml
4.create与apply的区别
kubectl run testpod --image nginx --dry-run=client -o yaml > test.yml kubectl create -f test.yml //运行yml文件（yml文件更改后不可更改） kubectl apply -f test.yml // yml运行后可以更改 kubectl delete pods testpod --force//删除pods
1.3.1基本命令
kubectl create deployment zee --image myapp:v1 --replicas 2// 用控制器创建可指定pod的数量
kubectl explain deployment// 查看资源帮助
kubectl edit deployments.apps zee//编辑控制器配置
kubectl patch deployments.apps zee -p '{"spec":{"replicas":2}}'//利用补丁更改控制器配置
kubectl delete deployments.apps zee//删除pod
kubectl run wyz --image nginx kubectl expose pod wyz --port 80 --target-port 80//对内暴露，使pod可在本机被访问 kubectl get service curl 10.109.202.74
kubectl edit service zee//将spec下的ClusterIP（对内，服务类型）改为NodePort
kubectl describe pods//查看详细信息
kubectl logs pods/zee//查看某一个pods的日志
kubectl run -it testpod --image busyboxplus//运行交互pod # ctrl + pq 退出不停止pod kubectl attach pods/testpod -it //再次进入pod
kubectl cp /etc/passwd wyz:/ kubectl exec pods/wyz -c wyz -it -- bin/sh（-c：指定容器）
1.3.2高级指令
1.利用命令生成yaml
kubectl create deployment zee --image buxybox --dry-run=client -o yaml > dep-zee.yml //创建控制器pod kubectl apply -f dep-zee.yml
2.删除pod
kubectl delete -f dep-zee.yml
3.查看标签，更改标签
标签功能，设定两个pod，更改一个标签后，控制器识别到少了一个zee标签的pod，于是它会再启动一个pod，将标签改回来后，控制器识别到多了一个pod，于是它会删除一个pod（控制器控制pod数量 ）
kubectl get pods --show-labels
kubectl get label pods zee-5f46cc654-8xc4h（name） app=xxx --overwrite
2.pod（k8s中最小控制单元）
pod是可以创建和管理k8s计算的最小可部署单元
多个容器间共享ipc network
kubectl get pods//查看当前pods kubectl get pods --all-namespace//查看所有pods kubectl get pods -o wide//可以看到pods名称等 kubectl get pods -o yaml//以yaml的形式查看
生成yml文件进行资源管理 kubectl run testpod1 --image nginx --dry-run=client -o yaml > testpod1.yml
命令式对配置（只能建立） kubectl create -f testpod1.yml
生命式对象配置（除了建立以外还可以做更新）kubectl apply -f testpod1.yml
2.1利用控制器管理pod
高可用性和高可靠性：1.自动故障恢复；2.健康检查和自愈
可扩展性：1.轻松扩缩容；2.水平自动扩缩容（HPA，无法单独运行）
版本管理和更新：1.滚动更新；2.回滚
声明式配置：1.简洁的配置方式；2.期望状态管理
服务发现和负载均衡：1.自动注册和发现；2.流量分发
多环境一致性：一致的部署方式
kubectl expose deployment zee --port 80 --target-port 80//进行暴露
kubectl delect services zee//如果在暴露时端口被占用，删除占用的服务，删除后重新暴露
kubectl describe service zee//显示资源的详细信息
pod的扩容和缩容
kubectl scale deployment zee --replicas 4//扩容，设置副本数量为4，缩容，更改副本数量（做四个负载均衡）
控制器自动负载均衡，前提是将pod暴露
2.2pod更新及回滚
网络插件有问题
kubectl delete -f kub-fannel.yaml//删除
kubectl apply -f kub-fannel.yaml//重新添加
1.kubectl create deployment zee --image myapp:v1 --replicas 2//创建两个控制器
2.暴露zee的端口
3.kubectl set image deployments/zee myapp=myapp:v2//更新版本为v2
4.kubectl rollout history deployment zee//查看版本更新
5.kubectl rollout undo deployment zee --to-revision 1//版本回滚
2.3利用yaml文件部署应用
清晰的表达期望，重复的利用，灵活和可扩展
kubectl api-resources//查看所有api版本
spec：详细定义对象
command：启动容器时要执行的命令
2.3.1运行多个pod
spec: containers: - image: nginx name: zee-container - image: buxybox:latest name: zee-container command: ["/bin/sh","-c","sleep 100000"]
2.3.2端口映射
spec: containers: - image: nginx name: zee-container ports: - name: webport containerPort: 80 hostPort: 80 protocol: TCP
如果没有进行端口暴露，则只能通过pod的ip来访问，如果暴露则可以通过主机的ip进行访问
2.3.3设定环境变量
spec: containers: - image: nginx name: zee-container command: ["/bin/sh","-c","echo $NAME;sleep 100000"] env: - name: "NAME" value: "wyingzee"
2.3.4资源限制
spec: containers: - image: nginx name: wenserver1 resources: limits: cpu: 1 memory: 200mi requests: cpu: 500m memory: 100mi
limits的值要大于requests，如果将limits的值设置的与request的值一样大，那么此时的优先级最大
2.3.5容器的启动管理
spec:
restartpolicy: Always
containers:
- image: nginx
name: wenserver1
command: ["/bin/sh", "-c","echo hello zee"]
Always：pod一旦终止运行不论是怎样终止的，kubernetes都会重启它（不管正不正确都不能终止）
Never：退出后就执行完了
OnFailure： 容器正常就不管，非正常就重启（必须正确终止）
2.3.6共享宿主机网络
spec: hostNetwork: true containers: - image: nginx name: wenserver1 command: ["/bin/sh", "-c","sleep 10000"]
2.4pod的生命周期
2.4.1init容器
pod可以包含多个容器，init容器的运行是一个接一个，init容器不支持readiness就绪探针
如果pod的init容器运行失败，那么kubernetes会不断重启该pod，知道init容器运行成功为止，但如果pod的restartpolicy的值是never，那么他就不会重新启动
2.4.1.1nit容器的功能
做主容器运行之前要做的事，如判断，运行一些指令让环境中有一些什么东西
Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。
由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动
2.4.1.2init容器示例
spec: containers: - image: nginx name: wyingzee initContainers: - image: busyboxplus:latest name: initnode command: ["sh","-c","until test -e /testfile;do echo wating for myservice; sleep 2 done"]
先运行init容器，运行成功后再运行上面的
2.4.2探针
主要功能：kubernetes对容器执行定期诊断
Execation：在容器内执行指定命令
2.4.2.1存活探针
spec: containers: - image: nginx name: wyingzee livenessProbe://探针类型 tcpSocket://tcp的方式检测 port: 8080 initalDelaySecond: 3//容器运行了多少秒后开始检测 periodSeconds: 1//每隔一秒检测一次 timoutSecounds: 1
livenessProbe:指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。
2.4.2.2就绪探针
spec: containers: - image: nginx name: wyingzee readinessProbe://探针类型 httpGet:# HTTPGetAction:对指定的端口和路径上的容器的IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。 path: /test.html prot: 80 initialDelaySeconds: 1 periodSeconds: 3 timeoutSeconds: 1
readinessProbe:指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Succes（没有准备好就不暴露出来，准备好就暴露出来）
3.控制器
3.1什么是控制器
控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目
Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod
当建立控制器后，会把期望值写入etcd，k8s中的apiserver检索etcd中我们保存的期望状态，并对比pod的当前状态，如果出现差异代码自驱动立即恢复
3.2控制器常用类型
ReplicaSet ：ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行 （无版本更新的能力）
Deployment： 一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力 （无状态，每次启动都是随机的）
DaemonSet： DaemonSet 确保全指定节点上运行一个 Pod 的副本
StatefulSet： StatefulSet 是用来管理有状态应用的工作负载 API 对象。（每次启动都是固定的）
Job： 执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束
CronJob： Cron Job 创建基于时间调度的 Jobs。
HPA全称Horizontal Pod Autoscaler ： 根据资源利用率自动调整service中Pod数量，实现Pod水平自动缩放（自动扩容和缩容，没有监控不能做）
3.3replicaset控制器（通过标签控制pod的数量，无法控制版本）
ReplicaSet和Replication Controller的唯一区别是选择器的支持，ReplicaSet支持新的基于集合的选择器需求
ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行
虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制
3.3.1replicaset示例
apiVersion: apps/v1 kind: ReplicaSet metadata: labels: app: replicaset name: replicaset spec: replicas: 2 selector: matchLabels: app: replicaset template: metadata: labels: app: replicaset spec: containers: - image: nginx name: nginx
3.4deployment 控制器（可以控制版本）
先控制replicaset，通过replicaset来控制pod
Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法
在Deployment中ReplicaSet相当于一个版本
用来创建Pod和ReplicaSet
滚动更新和回滚
扩容和缩容
暂停与恢复
3.4.1depolyment示例
apiVersion: apps/v1 kind: Deployment metadata: labels: app: zee name: zee spec: replicas: 4 selector: matchLabels: app: zee template: metadata: labels: app: zee spec: containers: - image: myapp:v2 name: myapp
3.4.2版本迭代
进入yml文件将v2改为v1，然后再次声明
想要被访问需要将端口暴露
kubectl expose deployment zee-dp --port 80 --target-port 80 --dry-run=client -o yaml >> zee.yml #将service追加在zee.yml后面
kubectl get svc zee #查看zee服务的信息
3.4.3版本回滚
将zee.yml中的v1改为v2
RollingUpdateStrategy: 25% max unavailable, 25% max surge//更新策略
3.4.4滚动更新策略
spec: minReadySeconds: 5 #最小就绪时间，指定pod每隔多久更新一次 replicas: 4 strategy: #指定更新策略 rollingUpdate: maxSurge: 1 #比定义pod数量多几个，最多比这四个多一个，在更新的时候一个一个来做 maxUnavailable: 0 #比定义pod个数少几个，必须保证这四个能用
3.4.5暂停及恢复
在生产中我们需要等所有的更新都完成后再上线
kubectl rollout pause deployment zee #将更新暂停
spec: containers: - image: nginx name: nginx resources: limits: cpu: 0.5 memory: 100mi resquests: cpu: 0.5 memory: 100mi #做资源限制，此时资源限制没有生效，因为更新被暂停了
kubectl rollout resume deployment zee #恢复更新
查看所有的是否都更新完
kubectl rollout history deployment zee
3.5daemonset控制器
DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时， 也会为他们新增一个 Pod ，当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod（有污点tains，不建立，pod可以设置对污点的容忍）
3.5.1daemonset示例（不能对pod的数量进行指定）
apiVersion: apps/v1 kind: DaemonSet metadata: labels: app: zee-dm name: zee-dm spec: selector: matchLabels: app: zee-dm template: metadata: labels: app: zee-dm spec: tolerations: #对于污点节点的容忍 - effect: NoSchedule operator: Exists #对污点强容忍 containers: - image: nginx name: nginx
将zee.yml复制为zee-dm.yml
做完容忍度后，pod就会再master节点上创建
3.6job控制器
Job，主要用于负责批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)任务
3.6.1job示例
apiVersion: batch/v1 kind: Job metadata: name: pi spec: completions: 6 #一共完成任务数为6 parallelism: 2 #每次并行完成2个 template: spec: containers: - name: pi image: perl:5.34.0 command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] 计算Π的后2000位 restartPolicy: Never #关闭后不自动重启 backoffLimit: 4 #运行失败后尝试4重新运行 [root@k8s2 pod]# kubectl apply -f job.yml
关于重启策略设置的说明：
如果指定为OnFailure，则job会在pod出现故障时重启容器
而不是创建pod，failed次数不变
如果指定为Never，则job会在pod出现故障时创建新的pod
并且故障pod不会消失，也不会重启，failed次数加1
如果指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了
3.7cronjob控制器
ron Job 创建基于时间调度的 Jobs。
CronJob控制器以Job控制器资源为其管控对象，并借助它管理pod资源对象，
CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。
CronJob可以在特定的时间点(反复的)去运行job任务。
3.7.1cronjob示例
apiVersion: batch/v1 kind: CronJob metadata: name: hello spec: schedule: "* * * * *" jobTemplate: spec: template: spec: containers: #是一个列表所以要加“-” - name: hello image: busybox imagePullPolicy: IfNotPresent #本地有就用本地的，没有就拉取 command: [" - /bin/sh -c date; echo Hello from the Kubernetes cluster"] restartPolicy: OnFailure #失败后对容器进行重启不记录在失败次数内 [root@k8s2 pod]# kubectl apply -f cronjob.yml
4.微服务
4.1什么是微服务
当pod的标签与微服务的标签一致时pod的业务就可以通过微服务发布出去
用控制器来完成集群的工作负载，那么应用如何暴漏出去？需要通过微服务暴漏出去后才能被访问
Service是一组提供相同服务的Pod对外开放的接口。
借助Service，应用可以实现服务发现和负载均衡。
service默认只支持4层负载均衡能力，没有7层功能。（可以通过Ingress实现）
4.2微服务的类型（四层）
ClusterIP： 默认值，k8s系统给service自动分配的虚拟IP，只能在集群内部访问
NodePort ：将Service通过指定的Node上的端口暴露给外部，访问任意一个NodeIP:nodePort都将路由到ClusterIP（在微服务中加入type）
LoadBalancer：在NodePort的基础上,借助cloud provider创建一个外部的负载均衡器，并将请求转发到 NodeIP:NodePort，此模式只能在云服务器上使用
ExternalName ：将服务通过 DNS CNAME 记录方式转发到指定的域名（通过 spec.externlName 设定
4.3ipvs
Service 是由 kube-proxy 组件，加上 iptables 来共同实现的
kube-proxy 通过 iptables 处理 Service 的过程，需要在宿主机上设置相当多的 iptables 规则，如果宿主机有大量的Pod，不断刷新iptables规则，会消耗大量的CPU资源
IPVS模式的service，可以使K8s集群支持更多量级的Pod
iptables会大量消耗资源，设置为ipvs会大大节省资源，并且使调度更加精准
4.3.1ipvs模式配置方式（service的工作模式优化）
kubectl -n kube-system edit cm kube-proxy #找到mode
kubectl -n kube-system get pod | awk '/proxy/{system("kubectl -n kube-system delete pods "$1)}'#将原有的pod删除，使它生成新的pod（刷新）
将pod删除后，策略也会消失
4.4clusterip
clusterip模式只能在集群内访问，并对集群内的pod提供健康检测和自动发现功能（通过标签实现）
1.先创建一个pod
kubectl run testpod --image nginx
2.为pod建立一个微服务，将pod发布
kubectl expose pod testpod --port 80 --target-port 80 --dry-run=client -o yaml > testpod.yml
apiVersion: v1 kind: Service metadata: labels: run: testpod name: testpod spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: testpod type: ClusterIp
3.新建一个pod，将pod的标签改为上一个服务的标签，它会自动发现并将pod加入到策略中
kubectl label pod testpod1 run=testpod --overwrite #新建一个pod
4.service创建后集群DNS提供解析
kubectl -n kube-system get svc #查看微服务的dns
dig testpod.default.svc.cluster.local@10.96.0.10（svc.cluster.local固定格式）
在集群内部可通过域名访问
4.4.1clusterIP中特殊的模式headless（无头服务）
客户端直接访问pod，而不是通过访问svc访问pod，暴露pod本身的ip且不会加入到ipvsadm的策略中
spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: timinglee type: ClusterIP clusterIP: None
4.5nodeport
通过ipvs暴漏端口从而使外部主机通过master节点的对外ip:<port>来访问pod业务
会在pod暴露一个端口，在访问的时候就访问这个端口
spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: timinglee type: ClusterIP clusterIP: NodePort
nodeport默认端口
nodeport默认端口是30000-32767，超出会报错，如果想要超出这个范围，则需要修改配置
vim /etc/kubernetes/manifests/kube-apiserver.yaml - --service-node-port-range=30000-40000 #修改参数后集群会自动重启
spec: ports: - port: 80 protocol: TCP targetPort: 80 nodePort: 33333 #指定端口 selector: app: timinglee type: NodePort
4.6loadbalancer
云平台会为我们分配vip并实现访问，如果是裸金属主机那么需要metallb来实现ip的分配
spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: timinglee type: LoadBalancer
配置完后，无法生成对外的ip，于是我们需要搭建matelLbn来分配对外的ip
4.7matelLb
为loadbalancer分配对外的ip
4.7.1下载matelLb
1.设置ipvs模式 [root@k8s-master ~]# kubectl edit cm -n kube-system kube-proxy apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration mode: "ipvs" ipvs: strictARP: true
[root@k8s-master ~]# kubectl -n kube-system get pods | awk '/kube-proxy/{system("kubectl -n kube-system delete pods "$1)}'
2.下载部署文件 [root@k8s2 metallb]# wget https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml
3.修改文件中镜像地址,与harbor仓库路径保持一致 [root@k8s-master ~]# vim metallb-native.yaml ... image: metallb/controller:v0.14.8 image: metallb/speaker:v0.14.8
4.上传镜像到harbor [root@k8s-master ~]# docker pull quay.io/metallb/controller:v0.14.8 [root@k8s-master ~]# docker pull quay.io/metallb/speaker:v0.14.8
[root@k8s-master ~]# docker tag quay.io/metallb/speaker:v0.14.8 reg.timinglee.org/metallb/speaker:v0.14.8 [root@k8s-master ~]# docker tag quay.io/metallb/controller:v0.14.8 reg.timinglee.org/metallb/controller:v0.14.8
[root@k8s-master ~]# docker push reg.timinglee.org/metallb/speaker:v0.14.8 [root@k8s-master ~]# docker push reg.timinglee.org/metallb/controller:v0.14.8
4.7.2部署服务
kubectl apply -f metallb-native.yaml kubectl get namespaces NAME STATUS AGE metallb-system Active 6s [root@k8s-master metalLbn]# vim configmap.yml apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: first-pool #地址池名称 namespace: metallb-system spec: addresses: - 172.25.254.50-172.25.254.99 #修改为自己本地地址段 --- #两个不同的kind中间必须加分割 apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: example namespace: metallb-system spec: ipAddressPools: - first-pool #使用地址池 kubectl apply -f configmap.yml [root@k8s-master metalLbn]# kubectl -n metallb-system get configmaps
此时就有对外的ip了
[root@k8s-master ~]# kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5d19h testpod LoadBalancer 10.96.214.227 172.25.254.50 80:31039/TCP 2s
4.8externalname
将外部的业务迁移到k8s时所用到
功能：在集群内指定一个svc把这个svc和外部的一个资源地址绑定
开启services后，不会被分配IP，而是用dns解析CNAME固定域名来解决ip变化问题
一般应用于外部业务和pod沟通或外部业务迁移到pod内时
在应用向集群迁移过程中，externalname在过度阶段就可以起作用了。
集群外的资源迁移到集群时，在迁移的过程中ip可能会变化，但是域名+dns解析能完美解决此问题
[root@k8s-master ~]# vim zee.yaml --- apiVersion: v1 kind: Service metadata: labels: app: zee-service name: zee-service spec: selector: app: zee type: ExternalName externalName: www.zee.org [root@k8s-master ~]# kubectl apply -f zee.yaml [root@k8s-master ~]# kubectl get services zee-service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE zee-service ExternalName <none> www.zee.org <none> 2m58s
4.9ingress-nginx
4.9.1ingress主要功能
主要功能：ingress借助services来访问pod
一种全局的、为了代理不同后端 Service 而设置的负载均衡服务,支持7层
Ingress由两部分组成：Ingress controller和Ingress服务
Ingress Controller 会根据你定义的 Ingress 对象，提供对应的代理能力。
业界常用的各种反向代理项目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已经为Kubernetes 专门维护了对应的 Ingress Controller。
4.9.2部署ingress
创建两个deployment，然后将他们以yml的形式暴露出去
将镜像上传到harper仓库
如果镜像有问题则需要再各个节点删除镜像
[root@k8s-master app]# docker load -i ingress-nginx-1.11.2.tag.gz Loaded image: reg.timinglee.org/ingress-nginx/controller:v1.11.2 Loaded image: reg.timinglee.org/ingress-nginx/kube-webhook-certgen:v1.4.3
[root@k8s-master app]# docker tag reg.timinglee.org/ingress-nginx/controller:v1.11.2 reg.wyz.org/ingress-nginx/controller:v1.11.2 [root@k8s-master app]# docker tag reg.timinglee.org/ingress-nginx/kube-webhook-certgen:v1.4.3 reg.wyz.org/ingress-nginx/kube-webhook-certgen:v1.4.3
[root@k8s-master app]# docker push reg.wyz.org/ingress-nginx/controller:v1.11.2
[root@k8s-master app]# docker push reg.wyz.org/ingress-nginx/kube-webhook-certgen:v1.4.3
kubectl apply -f deploy.yaml #安装
[root@k8s-master app] kubectl get namespaces NAME STATUS AGE ingress-nginx Active 30s#安装后会会建立一个域
安装失败
kubectl delete -f deploy.yaml #删除
修改文件，让它去我们的库下载
修改文件中的image
查看运行情况
[root@k8s-master app]# kubectl -n ingress-nginx get pods
现在就可以用了
4.9.3ingress示例
创建ingress发布svc
kubectl create ingress testpod --rule '*/=testpod:80' --dry-run=client -o yaml > ingress.yml #创建ingress
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: testpod spec: ingressClassName: nginx rules: - host: http: paths: - backend: service: name: testpod port: number: 80 path: / pathType: Prefix
kubectl -n ingress-nginx edit svc ingress-nginx-controller #修改微服务为loadbalancer
kubectl -n ingress-nginx get all #查看
kubectl get ingress NAME CLASS HOSTS ADDRESS PORTS AGE testpod nginx * 80 75s
此时访问它的外部IP就可以访问到pod
4.9.4ingress的高级用法
4.9.4.1基于路径访问
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: / name: testpod spec: ingressClassName: nginx rules: - host: http: paths: - backend: service: name: myappv1 port: number: 80 path: /v1 pathType: Prefix - backend: service: name: myappv2 port: number: 80 path: /v2 pathType: Prefix # 动静分离
kubectl describe ingress testpod # 查看
4.9.4.2基于域名的访问
在测试主机解析
vim /etc/hosts
建立基于域名的yml文件
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress2 spec: ingressClassName: nginx rules: - host: myappv1.timinglee.org http: paths: - backend: service: name: myapp-v1 port: number: 80 path: / pathType: Prefix - host: myappv2.timinglee.org http: paths: - backend: service: name: myapp-v2 port: number: 80 path: / pathType: Prefix