未安装ArgoCD参考GitOps实践之kubernetes部署Argocd1.查看ArgocdService可以看到是ClusterIP，因此不能从外部直接访问Argocd的WEB-UI#kubectlgetsvc-nargocdNAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGEargocd-applicationset-controllerClusterIP10.96.52.1097000/TCP,8080/TCP25dargocd-dex-serverClusterIP10.96.57.2175556/TCP,5557/TCP,5558/TCP25dargoc
一、Ingress理论1.1Ingress简介service的作用体现在两个方面，对集群内部，它不断跟踪pod的变化，更新endpoint中对应pod的对象，提供了ip不断变化的pod的服务发现机制；对集群外部，他类似负载均衡器，可以在集群内外部对pod进行访问。在Kubernetes中，Pod的IP地址和service的ClusterIP仅可以在集群网络内部使用，对于集群外的应用是不可见的。为了使外部的应用能够访问集群内的服务，Kubernetes目前提供了以下几种方案：●NodePort：将service暴露在节点网络上，NodePort背后就是Kube-Proxy，Kube-Proxy是
一、Ingress理论1.1Ingress简介service的作用体现在两个方面，对集群内部，它不断跟踪pod的变化，更新endpoint中对应pod的对象，提供了ip不断变化的pod的服务发现机制；对集群外部，他类似负载均衡器，可以在集群内外部对pod进行访问。在Kubernetes中，Pod的IP地址和service的ClusterIP仅可以在集群网络内部使用，对于集群外的应用是不可见的。为了使外部的应用能够访问集群内的服务，Kubernetes目前提供了以下几种方案：●NodePort：将service暴露在节点网络上，NodePort背后就是Kube-Proxy，Kube-Proxy是
在k8s应用中，如果你是通过云端防火墙和负载均衡搭配使用时，我们一般是这样与k8s集群中的服务进行通讯的：在云端防火墙安全配置中，配置你的公网域名在云端负载均衡中，为每个业务配置对应的k8s-ingress，通常一组业务相同的域名，对应同一个ingress在云端负载均衡中，配置转发到k8s-ingress暴露的IP+端口，http默认80、https默认443在k8s-ingress中添加对应的公网域名，选择对你的svck8s实际上，根据你的svc会动态转发到它绑定的endpoint上，也就是你实现的pod上当找到pod之后，整理路由请求也就结束的，之后请求处理后，将响应的结果原路返回，即可
在k8s应用中，如果你是通过云端防火墙和负载均衡搭配使用时，我们一般是这样与k8s集群中的服务进行通讯的：在云端防火墙安全配置中，配置你的公网域名在云端负载均衡中，为每个业务配置对应的k8s-ingress，通常一组业务相同的域名，对应同一个ingress在云端负载均衡中，配置转发到k8s-ingress暴露的IP+端口，http默认80、https默认443在k8s-ingress中添加对应的公网域名，选择对你的svck8s实际上，根据你的svc会动态转发到它绑定的endpoint上，也就是你实现的pod上当找到pod之后，整理路由请求也就结束的，之后请求处理后，将响应的结果原路返回，即可
问题的产生对于我们的容器化部署项目keycloak来说，当它从云端负载均衡LB直接通过NodePort转发到keycloak时，没有任务问题，一切正常；缺点就是，运维人员要维护一大批端口，哪个端口对应哪个服务，非常容易出乱子。问题的解决只要你不放弃，任何问题都可以解决，前提是不要走死胡同，因为你的方式可能是错误的，需要多尝试。所以，我们找到了不需要配置很多不同端口的方法，就是使用k8s-ingress来解决这个问题，我们用的是ingress/nginx，事实上，ingress也可以选择Treafik、Nginx、HAProxy、Istio，Kong等等集成的。最开始，在接入ingress时，非
问题的产生对于我们的容器化部署项目keycloak来说，当它从云端负载均衡LB直接通过NodePort转发到keycloak时，没有任务问题，一切正常；缺点就是，运维人员要维护一大批端口，哪个端口对应哪个服务，非常容易出乱子。问题的解决只要你不放弃，任何问题都可以解决，前提是不要走死胡同，因为你的方式可能是错误的，需要多尝试。所以，我们找到了不需要配置很多不同端口的方法，就是使用k8s-ingress来解决这个问题，我们用的是ingress/nginx，事实上，ingress也可以选择Treafik、Nginx、HAProxy、Istio，Kong等等集成的。最开始，在接入ingress时，非
身份认证在日常生活当中是非常常见的一项功能，大家平时基本都会接触到，ApacheAPISIX作为一个API网关，目前已开启与各种插件功能的适配合作，插件库也比较丰富，目前已经可与大量身份认证相关的插件进行搭配处理，如下图所示。基础认证插件比如Key-Auth、Basic-Auth，他们是通过账号密码的方式进行认证。复杂一些的认证插件如Hmac-Auth、JWT-Auth，如Hmac-Auth通过对请求信息做一些加密，生成一个签名，当API调用方将这个签名携带到APISIX，APISIX会以相同的算法计算签名，只有当签名方和应用调用方认证相同时才予以通过。其他则是一些通用认证协议和联合第三方组件
身份认证在日常生活当中是非常常见的一项功能，大家平时基本都会接触到，ApacheAPISIX作为一个API网关，目前已开启与各种插件功能的适配合作，插件库也比较丰富，目前已经可与大量身份认证相关的插件进行搭配处理，如下图所示。基础认证插件比如Key-Auth、Basic-Auth，他们是通过账号密码的方式进行认证。复杂一些的认证插件如Hmac-Auth、JWT-Auth，如Hmac-Auth通过对请求信息做一些加密，生成一个签名，当API调用方将这个签名携带到APISIX，APISIX会以相同的算法计算签名，只有当签名方和应用调用方认证相同时才予以通过。其他则是一些通用认证协议和联合第三方组件
本文是书稿《图解VPC&K8s网络模型》其中一篇。书稿还在继续写，进度不快也不慢，因为二哥不急也不躁。好肉需要慢炖，好书需要多磨。为什么要单独讲这个话题呢？因为我在和同事讨论K8s网络尤其是网络数据流向的时候，会反复提及到网络设备，无论它是物理的还是虚拟的。而网络设备在我们所讨论到的数据流场景里，时而在接收数据，时而在发送数据。也就是说它同时扮演着双重身份：Ingress和Egress。另外我在整理eBPF相关的内容，尤其是tceBPF的时候，再一次发现如果不能准确地在数据流中识别出网络设备是Ingress还是Egress，就无法将代码逻辑和实际运行结果对上号，更勿谈能理解tceBPF了。这样
