k8s 之 应用实践-Service,Ingress
1.背景;
由于简化部署k8s 集群 ，公司的k8s 部署方案使用的是 kubeadm ,且跟进线上线下维度进行集群划分，为何要使用kubeadm 主要有两个原因：1.部署方便快捷，2.k8s节点扩容方便 3.部署难度降低;
2.系统环境;
| 系统版本 | 内核版本 | etcd | 备注 |
| CentOS Linux release 7.5.1804 | 3.10.0-862.14.4.el7.x86_64 | etcdctl version: 3.3.11 | |
3.相关组件版本;
| kubeadmin 组件名称 | 组件版本名称 | 备注 |
k8s.gcr.io/kube-apiserver | v1.13.4 | kube-apiserver 是 Kubernetes 最重要的核心组件之一，主要提供以下的功能
|
k8s.gcr.io/kube-controller-manager | v1.13.4 | kube-scheduler 负责分配调度 Pod 到集群内的节点上，它监听 kube-apiserver，查询还未分配 Node 的 Pod，然后根据调度策略为这些 Pod 分配节点（更新 Pod 的 调度器需要充分考虑诸多的因素：
|
k8s.gcr.io/kube-scheduler | v1.13.4 | Controller Manager 由 kube-controller-manager 和 cloud-controller-manager 组成，是 Kubernetes 的大脑，它通过 apiserver 监控整个集群的状态，并确保集群处于预期的工作状态。 |
k8s.gcr.io/kube-proxy | v1.13.4 | 每台机器上都运行一个 kube-proxy 服务，它监听 API server 中 service 和 endpoint 的变化情况，并通过 iptables 等来为服务配置负载均衡（仅支持 TCP 和 UDP）。 kube-proxy 可以直接运行在物理机上，也可以以 static pod 或者 daemonset 的方式运行。 |
| k8s.gcr.io/pause | 3.1 | Kubernetes为每个Pod都附属了gcr.io/google_containers/pause:latest，这个容器只接管Pod的网络信息，业务容器通过加入网络容器的网络来实现网络共享。此容器随着pod创建而创建，随着Pod删除而删除，正如其名字"pause" 该容器是对业务pod的命名空间的解析。 |
| k8s.gcr.io/coredns | 1.2.6 | DNS 是 Kubernetes 的核心功能之一，通过 kube-dns 或 CoreDNS 作为集群的必备扩展来提供命名服务。 |
weaveworks/weave | 2.5.2 | Weave Net是一个多主机容器网络方案，支持去中心化的控制平面，各个host上的wRouter间通过建立Full Mesh的TCP链接，并通过Gossip来同步控制信息。这种方式省去了集中式的K/V Store，能够在一定程度上减低部署的复杂性， |
4.应用实践;
(1).集群已经正常运行如下所示;
2.查看deployment 配置;
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-dpspec: selector: matchLabels: app: nginx-dp replicas: 1 template: metadata: labels: app: nginx-dp spec: containers: - name: nginx image: nginx:alpine ports: - containerPort: 80
3.查看ervice 配置;
apiVersion: v1kind: Servicemetadata: name: nginx-dp-cpfspec: type: NodePort ports: - nodePort: 30001 port: 80 targetPort: 80 protocol: TCP selector: app: nginx-dp
4.查看生成endpoints
5.查看service 规则;
6.查看由kube-proxy 生成的iptables 防火墙规则; (正常规则)
注意:
1.如果防火墙规则出现 类似如下规则:
-A KUBE-EXTERNAL-SERVICES -p tcp -m comment --comment "default/nginx-dp-cpf: has no endpoints" -m addrtype --dst-type LOCAL -m tcp --dport 30001 -j REJECT --reject-with icmp-port-unreachable
2.解决办法;
(1).net.ipv4.ip_forward = 1 #系统内核路由转发功能
(2).iptables -P FORWARD ACCEPT #允许 iptables FORWARD 链规则通过;
(3).iptables -P OUTPUT ACCEPT #允许 iptables OUTPUT 链规则通过;
(4).检查deployment labels 和 service labels 设置是否关联正确;
(5).kubectl get endpoints --show-labels #注意此规则和防火墙规则匹配 若出现none 请检查防火墙规则;
7.进行功能测试 (k8s 集群内进行测试);
8.ingress 部署;
#master 端执行;kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yamlkubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/baremetal/service-nodeport.yaml
注意:
nodeSelector 字段 labels 和 node labels 关联; 否则运行ingres pod 出现 peding 状态;
8.ingress 配置;
##配置yamlapiVersion: extensions/v1beta1kind: Ingressmetadata: name: test-ingressspec: rules: - http: paths: - path: / backend: serviceName: test-nginx servicePort: 80
###查看创建 ingress;
####测试访问###
####基于域名多服务的 Ingress
路由到多服务的 Ingress 即根据请求路径的不同转发到不同的后端服务上，比如
www.breaklinux.com -> 10.109.21.77-> /test1 s1:80 -> /test2 s2:80
apiVersion: extensions/v1beta1kind: Ingressmetadata: name: testspec: rules: - host: www.breaklinux.com http: paths: - path: /test1 backend: serviceName: test-nginx servicePort: 80 - path: /test2 backend: serviceName: nginx-dp-test-01 servicePort: 80
###虚拟主机 Ingress
apiVersion: extensions/v1beta1kind: Ingressmetadata: annotations: nginx.ingress.kubernetes.io/configuration-snippet: "" nginx.ingress.kubernetes.io/proxy-body-size: 10240m nginx.ingress.kubernetes.io/proxy-read-timeout: "36000" nginx.ingress.kubernetes.io/proxy-send-timeout: "36000" nginx.ingress.kubernetes.io/rewrite-target: /$1 nginx.ingress.kubernetes.io/ssl-redirect: "false" name: test-nginx-ingessspec: rules: - host: test-nginx-ingress.dev.k8s.chj.cloud http: paths: - backend: serviceName: test-nginx servicePort: 80 path: /?(.*)
##基于虚拟主机访问测试#
##因为没有dns 服务环境 绑定hosts 进行测试
cat /etc/hosts10.109.21.77 www.breaklinux.com test-nginx-ingress.dev.k8s.chj.cloud
