An edge-native container management system for edge computing

English | 简体中文

SuperEdge

What is SuperEdge?

SuperEdge is an open source container management system for edge computing to manage compute resources and container applications in multiple edge regions. These resources and applications, in the current approach, are managed as one single Kubernetes cluster. A native Kubernetes cluster can be easily converted to a SuperEdge cluster.

SuperEdge has the following characteristics:

  • Kubernetes-native: SuperEdge extends the powerful container orchestration and scheduling capabilities of Kubernetes to the edge. It makes nonintrusive enhancements to Kubernetes and is fully compatible with all Kubernetes APIs and resources. Kubernetes users can leverage SuperEdge easily for edge environments with minimal learning.
  • Edge autonomy: SuperEdge provides L3 edge autonomy. When the network connection between the edge and the cloud is unstable, or the edge node is offline, the node can still work independently. This eliminates the negative impact of unreliable network.
  • Distributed node health monitoring: SuperEdge provides edge-side health monitoring capabilities. SuperEdge can continue to monitor the processes on the edge side and collect health information for faster and more accurate problem discovery and reporting. In addition, its distributed design can provide multi-region monitoring and management.
  • Built-in edge orchestration capability: SuperEdge supports automatic deployment of multi-regional microservices. Edge-side services are closed-looped, and it effectively reduces the operational overhead and improves the fault tolerance and availability of the system.
  • Network tunneling: SuperEdge ensures that Kubernetes nodes can operate under different network situations. It supports network tunnelling using TCP, HTTP and HTTPS.

SuperEdge was initiated by the following companies: Tencent, Intel, VMware, Huya, Cambricon, Captialonline and Meituan.

Architecture

Cloud components:

  • tunnel-cloud: Maintains a persistent network connection to tunnel-edge services. Supports TCP/HTTP/HTTPS network proxies.
  • application-grid controller: A Kubernetes CRD controller as part of ServiceGroup. It manages DeploymentGrids and ServiceGrids CRDs and control applications and network traffic on edge worker nodes.
  • edge- admission: Assists Kubernetes controllers by providing real-time health check status from edge-health services distributed on all edge worker nodes.

Edge components:

  • lite-apiserver: Lightweight kube-apiserver for edge autonomy. It caches and proxies edge components' requests and critical events to cloud kube-apiserver.
  • edge-health: Monitors the health status of edge nodes in the same edge region.
  • tunnel-edge: Maintains persistent connection to tunnel-cloud to retrieve API requests to the controllers on the edge.
  • application-grid wrapper: Managed by application-grid controller to provide independent internal network space for services within the same ServiceGrid.

Quickstart Guide

For installation, deployment, and administration, see our Tutorial.

Contact

For any question or support, feel free to contact us via:

Contributing

Welcome to contribute and improve SuperEdge

License

Apache License 2.0

Owner
SuperEdge
An edge computing working group
SuperEdge
https://github.com/superedge/superedge
Comments
  • [Question]边缘节点tunnel-edge反复重启，且无法正常查看pod日志及无法SSH连接

    [Question]边缘节点tunnel-edge反复重启，且无法正常查看pod日志及无法SSH连接

    边缘节点tunnel-edge反复重启，同时也无法查看日志，ssh连接也无法使用，pod部署是可以正常进行。尝试很多次，不知道出现问题在哪里

    全部通过一键安装程序edgeadm部署，边缘节点信息 System OS: ubuntu 20.04 （VMware 虚拟机系统） kubernetes-version：1.20.6 Superedge -version: 0.7.0

    截屏2022-07-04 上午12 25 20

    以下为kubectl describe tunnel-edge出现异常的信息 Normal Scheduled 44m default-scheduler Successfully assigned edge-system/tunnel-edge-8tnbh to edge-dev Normal Pulling 44m kubelet Pulling image "superedge.tencentcloudcr.com/superedge/tunnel:v0.7.0" Normal Pulled 44m kubelet Successfully pulled image "superedge.tencentcloudcr.com/superedge/tunnel:v0.7.0" in 15.57385848s Normal Killing 34m kubelet Container tunnel-edge failed liveness probe, will be restarted Normal Created 30m (x5 over 44m) kubelet Created container tunnel-edge Normal Started 30m (x5 over 43m) kubelet Started container tunnel-edge Warning Unhealthy 28m (x5 over 43m) kubelet Liveness probe failed: HTTP probe failed with statuscode: 500 Warning BackOff 9m6s (x59 over 37m) kubelet Back-off restarting failed container Normal Pulled 4m5s (x9 over 40m) kubelet Container image "superedge.tencentcloudcr.com/superedge/tunnel:v0.7.0" already present on machine

    边缘节点docker tunnel-edge日志信息： I0703 16:25:59.464005 1 server.go:42] Versions: version.Info{GitVersion:"v0.7.0", GitBranch:"v0.7.0", GitCommit:"75b97d99f0f029a9f898f1f7992089093f602dc2", GitTreeState:"clean", BuildDate:"2022-06-17T07:16:49Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"} I0703 16:25:59.464310 1 streaminterceptor.go:257] stream clinet token nodename = edge-dev token = BpLnfgDsc2WD8F2qNfHK5a84jjJkwzDk I0703 16:25:59.464342 1 stream.go:85] init module: stream success ! I0703 16:25:59.464352 1 egress.go:81] init module: egress success ! I0703 16:25:59.464360 1 tcp.go:87] init module: tcp success ! I0703 16:25:59.464362 1 https.go:51] init module: https success ! I0703 16:25:59.464383 1 ssh.go:60] init module: ssh success ! I0703 16:25:59.464393 1 core.go:31] starting module:https I0703 16:25:59.464397 1 core.go:33] start module:https success ! I0703 16:25:59.464400 1 core.go:31] starting module:ssh I0703 16:25:59.464405 1 core.go:33] start module:ssh success ! I0703 16:25:59.464410 1 core.go:31] starting module:stream I0703 16:25:59.464434 1 core.go:33] start module:stream success ! I0703 16:25:59.464436 1 core.go:31] starting module:egress I0703 16:25:59.464439 1 core.go:33] start module:egress success ! I0703 16:25:59.464441 1 core.go:31] starting module:tcp I0703 16:25:59.464466 1 core.go:33] start module:tcp success ! I0703 16:25:59.558325 1 grpcserver.go:108] channelz server listening address is not configured I0703 16:25:59.657672 1 grpcserver.go:99] log server listen on 0.0.0.0:51010

  • 云边隧道读取数据异常，云上的应用访问边缘节点应用失败

    云边隧道读取数据异常，云上的应用访问边缘节点应用失败

    What happened: 从云上访问边缘节点的应用，通过访问边缘节点应用的svc、clusterip、pod ip都不行，查到tunnel-cloud和tunnel-edge的报错，是连接超时，如下截图 image image

    Environment:

    • SuperEdge version: 0.7.0, tunnel-cloud/tunnel-edge 0.8.0
    • Kubernetes version (use kubectl version): 1.20.6
    • OS (e.g. cat /etc/os-release): ubuntu 18
    • Hardware configuration (e.g. lscpu) 4c 8g
  • [Question]通过edgeadm新部署的环境，会照成kube-flannel和edge-health反复重启

    [Question]通过edgeadm新部署的环境，会照成kube-flannel和edge-health反复重启

    @dodiadodia 今天在新的服务器上面程序部署了一次，又出现反复重启的问题。主要原因是edge-coredns连接超时照成相应kube-flannel和edge-health反复重启

    边缘master节点配置 ubuntu 20.04.4（阿里云提供ubuntu镜像） kubernetes-version：1.22.6 Superedge -version: 0.8.0

    边缘edge节点配置 System OS: ubuntu 20.04.4 （VM虚拟机系统） kubernetes-version：1.22.6 Superedge -version: 0.8.0

    错误日志信息 [INFO] plugin/ready: Still waiting on: "kubernetes" [INFO] plugin/ready: Still waiting on: "kubernetes" [INFO] plugin/ready: Still waiting on: "kubernetes" [INFO] plugin/ready: Still waiting on: "kubernetes" I0726 08:28:13.930752 1 trace.go:116] Trace[336122540]: "Reflector ListAndWatch" name:pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105 (started: 2022-07-26 08:27:43.929739635 +0000 UTC m=+62.910295058) (total time: 30.000954578s): Trace[336122540]: [30.000954578s] [30.000954578s] END E0726 08:28:13.930870 1 reflector.go:153] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105: Failed to list *v1.Service: Get "https://10.244.0.1:443/api/v1/services?limit=500&resourceVersion=0": dial tcp 10.244.0.1:443: i/o timeout I0726 08:28:13.932471 1 trace.go:116] Trace[208240456]: "Reflector ListAndWatch" name:pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105 (started: 2022-07-26 08:27:43.931524426 +0000 UTC m=+62.912079879) (total time: 30.00089309s): Trace[208240456]: [30.00089309s] [30.00089309s] END E0726 08:28:13.933875 1 reflector.go:153] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105: Failed to list *v1.Namespace: Get "https://10.244.0.1:443/api/v1/namespaces?limit=500&resourceVersion=0": dial tcp 10.244.0.1:443: i/o timeout I0726 08:28:14.016125 1 trace.go:116] Trace[646203300]: "Reflector ListAndWatch" name:pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105 (started: 2022-07-26 08:27:43.932571809 +0000 UTC m=+62.913127235) (total time: 30.083057354s): Trace[646203300]: [30.083057354s] [30.083057354s] END E0726 08:28:14.016162 1 reflector.go:153] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105: Failed to list *v1.Endpoints: Get "https://10.244.0.1:443/api/v1/endpoints?limit=500&resourceVersion=0": dial tcp 10.244.0.1:443: i/o timeout [INFO] plugin/ready: Still waiting on: "kubernetes"

    1658824948662

  • 集群内新增一个边缘节点后，该节点上的edge-coredns无法正常启动

    集群内新增一个边缘节点后，该节点上的edge-coredns无法正常启动

    各位好，目前有个疑问想请教一番： 我在集群内额外新增了一个节点(tc)(之前已有pre001这个边缘节点)，该新增的节点上的edge-coredns组件总是无法正常启动，查看日志提示 Listen: listen tcp 169.254.20.11:53: bind: cannot assign requested address ，经检查发现该节点ping 169.254.20.11 不通，而之前已经加入集群的节点是可以ping通的，想请问一下针对一个集群内有多边缘节点的这种情况，该如何处理呢？还望大佬们可指点迷津，不吝感谢！ 列表 日志

  • superedge部署--编译环境

    superedge部署--编译环境

    环境是kubernetes V1.16.15 docker-ce:18.09.9 golang:1.15.5 请教一下：执行下面命令报错 [root@master ~]# kubectl apply -f tunnel-coredns.yaml error: error parsing tunnel-coredns.yaml: error converting YAML to JSON: yaml: line 90: mapping values are not allowed in this context 是不是需要编译环境，编译的二进制文件tar.gz在哪里获取 谢谢！

  • 停止服务器后，改变公网再次重启，kubectl port-forward出现异常

    停止服务器后，改变公网再次重启，kubectl port-forward出现异常

    What happened: 关闭服务器且公网IP发生改变后，再次重启服务器，kubectl port-forward无法进行正确代理。出现以下异常信息 error: error upgrading connection: error dialing backend: proxy error from tunnel-cloud.edge-system.svc.cluster.local:8000 while dialing master:10250, code 500: 500 Internal Server Error kubectl代理全部失效，目前只发现该问题。不知如何排查，请赐教！

    What you expected to happen:

    How to reproduce it (as minimally and precisely as possible): 使用如下命令或者相应svc都会异常 kubectl port-forward --address 0.0.0.0 svc/edge-health-admission -n edge-system 30333:443

    Environment:

    • SuperEdge version: SuperEdge V0.8
    • Kubernetes version Kubernetes V1.22.6
    • OS (e.g. cat /etc/os-release): 阿里云 Ubuntu 20.04
  • Use edgeadm to install superedge v0.6.0

    Use edgeadm to install superedge v0.6.0

    I use the edgeadm to install the superedge v0.6.0. However, it fails. Part of the logs is as follows

    I1104 12:53:30.737691   34938 round_trippers.go:445] POST https://192.168.100.201:6443/apis/superedge.io/v1/namespaces/edge-system/deploymentgrids 404 Not Found in 0 milliseconds
I1104 12:53:30.737779   34938 deploy_edge_coredns.go:82] Waiting deploy edge-coredns DeploymentGrid, system message: the server could not find the requested resource (post deploymentgrids.superedge.io)
I1104 12:53:33.740334   34938 round_trippers.go:445] POST https://192.168.100.201:6443/apis/superedge.io/v1/namespaces/edge-system/deploymentgrids 404 Not Found in 1 milliseconds
I1104 12:53:33.740435   34938 deploy_edge_coredns.go:82] Waiting deploy edge-coredns DeploymentGrid, system message: the server could not find the requested resource (post deploymentgrids.superedge.io)

    I want to know what should I do? Thanks.

  • 在已有k8s集群上部署superedge 报错 panic: runtime error: invalid memory address or nil pointer dereference

    在已有k8s集群上部署superedge 报错 panic: runtime error: invalid memory address or nil pointer dereference

    What happened: 在已有k8s环境上部署报错 panic: runtime error: invalid memory address or nil pointer dereference

    What you expected to happen:

    How to reproduce it (as minimally and precisely as possible):

    Anything else we need to know?:

    Environment:

    • SuperEdge version: v0.7
    • Kubernetes version (use kubectl version): v1.20.7
    • OS (e.g. cat /etc/os-release): centos7.9
    • Kernel (e.g. uname -a): 5.18.5-1.el7.elrepo.x86_64
    • Hardware configuration (e.g. lscpu) 2c/4G/160G
    • Go Version (e.g. go version)
    • Others:
  • [Question] /tmp Permission changed after running edgeadm addon edge-apps

    [Question] /tmp Permission changed after running edgeadm addon edge-apps

    ENV:

    lsb_release -a :

    Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.6 LTS
Release:	18.04
Codename:	bionic

    kubectl version:

    Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.12", GitCommit:"4bf2e32bb2b9fdeea19ff7cdc1fb51fb295ec407", GitTreeState:"clean", BuildDate:"2021-10-27T17:12:26Z", GoVersion:"go1.15.15", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.15", GitCommit:"8f1e5bf0b9729a899b8df86249b56e2c74aebc55", GitTreeState:"clean", BuildDate:"2022-01-19T17:23:01Z", GoVersion:"go1.15.15", Compiler:"gc", Platform:"linux/amd64"}

    Process:

    1. Only single k8s master running on my laptop, no other node;
    2. Install calico as cni;
    3. Running sudo edgeadm addon edge-apps --master-public-addr doujohnerk8smaster.com on master;

    Result:

    To run ls -lad /tmp , its permissions seem be changed: drwxrw_rwt 3 root root 4096 Feb 14 11:42 /tmp, which leads to bash: cannot create temp file for here-document: Permission denied if I tried to autocomplete my command. And I have to manually add umask chmod 1777 /tmp to make it work;

  • Container all faild, lite--apiserver start faild when restart edge node

    Container all faild, lite--apiserver start faild when restart edge node

    What happened: If you restart the edge node vm , the lite-apiserver can't start success, and all the docker containers in edge node restart fail as well. therefor edge node status is NotReady

    image

    image

    image

    What you expected to happen:

    Restart the edge node should not result in such things.

    How to reproduce it (as minimally and precisely as possible): Just input the cmd "shutdown -r now" or "reboot" in vm where install the edge node component

    Environment:

    • SuperEdge version: v0.7.0
    • Kubernetes version (use kubectl version): 1.20.6
    • OS (e.g. cat /etc/os-release): Ubuntu 18.04.5 LTS (Bionic Beaver)
    • Kernel (e.g. uname -a): Linux edge-node-fuqiang 5.4.0-42-generic #46~18.04.1-Ubuntu SMP Fri Jul 10 07:21:24 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
    • Hardware configuration (e.g. lscpu): 4c 8g
  • [Question] CNCF SIG-Runtime Discussion/Presentation?

    [Question] CNCF SIG-Runtime Discussion/Presentation?

    Hello SuperEdge team,

    I'm one of the co-chairs of the CNCF SIG-Runtime, I'm reaching out and think it would be great for you to present/discuss the project at one of our meetings. An overview of the project would be great.

    Let me know if this something you'd be interested in doing. If yes, please feel free to add it to our agenda or reach out to me (raravena80 at gmail.com)

    Thanks!

  • 启动pods时，显示proxy error 的错误

    启动pods时，显示proxy error 的错误

    在superEdge0.8.1，k8s:1.22的版本上部署deployment 时，出现了proxy error的错误。 image 而在lg-edgedev-38的服务器上，10250 的端口是开的 image 同样的yaml 在superEdge0.7.0 上部署deployment 是正常的，请问大佬们这个要怎么解决？ @dodiadodia，@malc0lm ，@00pf00

  • 搭建高可用集群 除init的master节点外其余master节点缺少文件

    搭建高可用集群 除init的master节点外其余master节点缺少文件

    What happened: 搭建三个master节点，除了init的master节点外，剩余两个join的master节点缺少egress-selector-configuration.yaml、kube-scheduler-config.yaml和kube-scheduler-policy.cfg、tunnel-anp-client证书文件，导致kube-scheduler-master和kube-apiserver-master无法正常启动。 What you expected to happen: 修复该问题。 How to reproduce it (as minimally and precisely as possible): 搭建多master集群。

    Environment:

    • SuperEdge version: 0.8
    • Kubernetes version (use kubectl version): 1.22.6
    • OS (e.g. cat /etc/os-release): centos7.9
    • Kernel (e.g. uname -a): 5.4
    • Hardware configuration (e.g. lscpu) 4
  • [Question] Prometheus采集不到边端mysql exporter数据

    [Question] Prometheus采集不到边端mysql exporter数据

    Prometheus可以采集到边端node exporter数据，但是采集不到边端mysql exporter数据，具体报错如下：

    mysql exporter: image

    prometheus configmap image

    superedge版本： image

    K8S版本：1.20.6

    mysql pod网络
    hostNetwork: true

  • 边缘节点和 apiserver 断网后，coredns 会提示watch 问题

    边缘节点和 apiserver 断网后，coredns 会提示watch 问题

    What happened: 当 边缘节点和 Master 失联后，边缘节点的 pod 会 watch 本地 lite-apiserver，client-go 会提示下面的 Warning （例如 coredns 日志），需要深度 debug下 lite-apiserver 对 watch 的实现支持

    image

    What you expected to happen:

    How to reproduce it (as minimally and precisely as possible):

    Anything else we need to know?:

    Environment:

    • SuperEdge version:
    • Kubernetes version (use kubectl version):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Hardware configuration (e.g. lscpu)
    • Go Version (e.g. go version)
    • Others:
  • edge node label nodeunhealth: yes

    edge node label nodeunhealth: yes

    What happened: I built a SuperEdge cluster. There are a master node in cloud and three edge nodes using a NAT router visit cloud node. All components in namespace edge-system and kube-system works well. But I found all of the edge nodes has label nodeunhealth: yes which seems edge node are all unhealthy.

    root@master:~# kubectl describe node edgenode2|grep health
                    nodeunhealth: yes
  edge-system                 edge-health-z69wr                      10m (0%)      50m (2%)    20Mi (0%)        100Mi (2%)     10h

    When I disconnect cloud edge network and I found control plane Taints the edge node and drive out pods in disconnected edge node.

    root@master:~# kubectl logs pod/edge-health-z69wr -nedge-system
I1024 14:38:46.470417       1 server.go:39] Versions: version.Info{GitVersion:"v0.8.0", GitBranch:"main", GitCommit:"4df29b218b82f43b6fdca5259a83faeb208240ff", GitTreeState:"dirty", BuildDate:"2022-07-25T08:57:45Z", GoVersion:"go1.18.4", Compiler:"gc", Platform:"linux/amd64"}
I1024 14:38:46.470449       1 flag.go:31] FLAG: --add-dir-header="false"
I1024 14:38:46.470452       1 flag.go:31] FLAG: --alsologtostderr="false"
I1024 14:38:46.470454       1 flag.go:31] FLAG: --communicateperiod="0"
I1024 14:38:46.470456       1 flag.go:31] FLAG: --communicateretrytime="0"
I1024 14:38:46.470457       1 flag.go:31] FLAG: --communicateserverport="0"
I1024 14:38:46.470458       1 flag.go:31] FLAG: --communicatetimetout="0"
I1024 14:38:46.470460       1 flag.go:31] FLAG: --healthcheckperiod="0"
I1024 14:38:46.470462       1 flag.go:31] FLAG: --healthcheckscoreline="0"
I1024 14:38:46.470464       1 flag.go:31] FLAG: --help="false"
I1024 14:38:46.470466       1 flag.go:31] FLAG: --hostname=""
I1024 14:38:46.470468       1 flag.go:31] FLAG: --kubeconfig=""
I1024 14:38:46.470469       1 flag.go:31] FLAG: --kubeletauthplugin="{{KubeletAuthCheck 5 3 1 10250 false}}"
I1024 14:38:46.470476       1 flag.go:31] FLAG: --kubeletplugin="{{ 0 0 0 0 false}}"
I1024 14:38:46.470479       1 flag.go:31] FLAG: --log-backtrace-at=":0"
I1024 14:38:46.470480       1 flag.go:31] FLAG: --log-dir=""
I1024 14:38:46.470482       1 flag.go:31] FLAG: --log-file=""
I1024 14:38:46.470483       1 flag.go:31] FLAG: --log-file-max-size="1800"
I1024 14:38:46.470484       1 flag.go:31] FLAG: --log-flush-frequency="5s"
I1024 14:38:46.470486       1 flag.go:31] FLAG: --logtostderr="true"
I1024 14:38:46.470487       1 flag.go:31] FLAG: --masterurl=""
I1024 14:38:46.470488       1 flag.go:31] FLAG: --one-output="false"
I1024 14:38:46.470489       1 flag.go:31] FLAG: --pingplugin="{{ 0 0 0 0 false}}"
I1024 14:38:46.470492       1 flag.go:31] FLAG: --skip-headers="false"
I1024 14:38:46.470493       1 flag.go:31] FLAG: --skip-log-headers="false"
I1024 14:38:46.470494       1 flag.go:31] FLAG: --stderrthreshold="2"
I1024 14:38:46.470508       1 flag.go:31] FLAG: --v="2"
I1024 14:38:46.470510       1 flag.go:31] FLAG: --version="false"
I1024 14:38:46.470512       1 flag.go:31] FLAG: --vmodule=""
I1024 14:38:46.470513       1 flag.go:31] FLAG: --voteperiod="0"
I1024 14:38:46.470514       1 flag.go:31] FLAG: --votetimeout="0"
W1024 14:38:46.470519       1 client_config.go:615] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I1024 14:38:46.470966       1 initialize.go:56] Init: Host name is edgenode2
I1024 14:38:46.470971       1 initialize.go:63] common.hostname is edgenode2
I1024 14:38:46.554644       1 initialize.go:70] Init: host ip is 192.168.56.11
E1024 14:38:46.554922       1 check.go:71] GetNodeList: can't get node with hostname edgenode2, err: node "edgenode2" not found
I1024 14:39:06.728885       1 vote.go:134] update no vote of edgenode2 to master
I1024 14:39:06.815597       1 vote.go:134] update no vote of edgenode1 to master
E1024 14:43:06.871390       1 communicate.go:159] Communicate Client: communicate to 192.168.56.12 failed Put "http://192.168.56.12:51005/result": dial tcp 192.168.56.12:51005: connect: connection refused
I1024 14:43:06.977189       1 vote.go:134] update no vote of edgenode3 to master
E1024 14:43:16.872062       1 communicate.go:159] Communicate Client: communicate to 192.168.56.12 failed Put "http://192.168.56.12:51005/result": dial tcp 192.168.56.12:51005: connect: connection refused
E1024 14:43:26.873515       1 communicate.go:159] Communicate Client: communicate to 192.168.56.12 failed Put "http://192.168.56.12:51005/result": dial tcp 192.168.56.12:51005: connect: connection refused
E1024 14:43:36.875296       1 communicate.go:159] Communicate Client: communicate to 192.168.56.12 failed Put "http://192.168.56.12:51005/result": dial tcp 192.168.56.12:51005: connect: connection refused
E1024 14:43:46.886893       1 communicate.go:159] Communicate Client: communicate to 192.168.56.12 failed Put "http://192.168.56.12:51005/result": dial tcp 192.168.56.12:51005: connect: connection refused
E1024 14:43:56.894940       1 communicate.go:159] Communicate Client: communicate to 192.168.56.12 failed Put "http://192.168.56.12:51005/result": dial tcp 192.168.56.12:51005: connect: connection refused
W1024 15:32:25.375596       1 reflector.go:441] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: watch of *v1.Node ended with: an error on the server ("unable to decode an event from the watch stream: stream error: stream ID 41; INTERNAL_ERROR") has prevented the request from succeeding
W1024 15:32:25.375970       1 reflector.go:441] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: watch of *v1.ConfigMap ended with: an error on the server ("unable to decode an event from the watch stream: stream error: stream ID 39; INTERNAL_ERROR") has prevented the request from succeeding
W1024 16:01:51.850216       1 reflector.go:441] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: watch of *v1.Node ended with: very short watch: pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Unexpected watch close - watch lasted less than a second and no items received
W1024 16:01:51.850246       1 reflector.go:441] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: watch of *v1.ConfigMap ended with: very short watch: pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Unexpected watch close - watch lasted less than a second and no items received

    What you expected to happen: I do not know why edge health pod think edge node is unhealthy, But there must be somethings wrong. How to reproduce it (as minimally and precisely as possible): Building a SuperEdge cluster following official guide using edgeadm tools 0.8.0. And you will found this problem. Anything else we need to know?: Nothing. Environment:

    • SuperEdge version:0.8.0
    • Kubernetes version (use kubectl version):v1.22.6
    • OS (e.g. cat /etc/os-release):Ubuntu 20.04.5 LTS
    • Kernel (e.g. uname -a):Linux master 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
    • Hardware configuration (e.g. lscpu)12th Gen Intel(R) Core(TM) i7-12700F
    • Go Version (e.g. go version) no golang
    • Others:
  • [Question]the edge-coredns has issue of resolve dns

    [Question]the edge-coredns has issue of resolve dns

    hi team, i am working on superedge (amd64-v0.7.0-k8s-1.20.6) and hit the dns resolve issue on pods which are scheduled on edge nodes. it can't resolve the service in pod(edge side), for example, failed to resolve a service zhjc-admin-web-svc in namespace ns-ddj1faqs: 10.103.221.101 is the cluster ip of service edge-system/ edge-coredns-svc, the service link 3 edge-coredns pods for 2 edge nodes and master node:

    bash-4.4# cat /etc/resolv.conf 
nameserver 10.103.221.101
search ns-ddj1faqs.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
bash-4.4# 
bash-4.4# nslookup zhjc-admin-web-svc
nslookup: can't resolve '(null)': Name does not resolve

nslookup: can't resolve 'zhjc-admin-web-svc': Try again
bash-4.4# nslookup zhjc-admin-web-svc.ns-ddj1faqs
nslookup: can't resolve '(null)': Name does not resolve

nslookup: can't resolve 'zhjc-admin-web-svc.ns-ddj1faqs': Try again

    below is my edge-coredns configmap:

    apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health {
          lameduck 5s
        }
        hosts /etc/edge/hosts {
            reload 300ms
            fallthrough
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload 2s
        loadbalance
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2022-04-08T06:07:58Z"
  name: edge-coredns
  namespace: edge-system

    i try to bind the 10.103.221.101 in the edge-coredns configmap, but it cause the edge-coredns pods start failed with error:

    [ERROR] Restart failed: Listen: listen tcp 10.103.221.101:53: bind: cannot assign requested address
[ERROR] plugin/reload: Corefile changed but reload failed: starting with listener file descriptors: Listen: listen tcp 10.103.221.101:53: bind: cannot assign requested address

    cloud you please help to figure out how to troubleshooting this issue, any help will be really appreciated.

Related tags
Cloud Computing superedge
cloud-native local storage management system
 cloud-native local storage management system

Open-Local是由多个组件构成的本地磁盘管理系统，目标是解决当前 Kubernetes 本地存储能力缺失问题。通过Open-Local，使用本地存储会像集中式存储一样简单。

Dec 30, 2022
Production-Grade Container Scheduling and Management
 Production-Grade Container Scheduling and Management

Kubernetes (K8s) Kubernetes, also known as K8s, is an open source system for managing containerized applications across multiple hosts. It provides ba

Dec 28, 2022
Container Storage Interface driver for Synology NAS

Synology CSI Driver for Kubernetes The official Container Storage Interface driver for Synology NAS. Container Images & Kubernetes Compatibility Drive

Jan 5, 2023
Cloud-native way to provide elastic Jupyter Notebook services on Kubernetes
 Cloud-native way to provide elastic Jupyter Notebook services on Kubernetes

elastic-jupyter-operator: Elastic Jupyter on Kubernetes Kubernetes 原生的弹性 Jupyter 即服务 介绍 为用户按需提供弹性的 Jupyter Notebook 服务。elastic-jupyter-operator 提供以下特性

Dec 29, 2022
A Cloud Native Buildpack for Go

The Go Paketo Buildpack provides a set of collaborating buildpacks that enable the building of a Go-based application.

Dec 14, 2022
Elkeid is a Cloud-Native Host-Based Intrusion Detection solution project to provide next-generation Threat Detection and Behavior Audition with modern architecture.
 Elkeid is a Cloud-Native Host-Based Intrusion Detection solution project to provide next-generation Threat Detection and Behavior Audition with modern architecture.

Elkeid is a Cloud-Native Host-Based Intrusion Detection solution project to provide next-generation Threat Detection and Behavior Audition with modern architecture.

Dec 30, 2022
Nocalhost is Cloud Native Dev Environment.
 Nocalhost is Cloud Native Dev Environment.

Most productive way to build cloud-native applications. Nocalhost The term Nocalhost originates from No Local, which is a cloud-native development too

Dec 29, 2022
Cloudpods is a cloud-native open source unified multi/hybrid-cloud platform developed with Golang
 Cloudpods is a cloud-native open source unified multi/hybrid-cloud platform developed with Golang

Cloudpods is a cloud-native open source unified multi/hybrid-cloud platform developed with Golang, i.e. Cloudpods is a cloud on clouds. Cloudpods is able to manage not only on-premise KVM/baremetals, but also resources from many cloud accounts across many cloud providers. It hides the differences of underlying cloud providers and exposes one set of APIs that allow programatically interacting with these many clouds.

Jan 11, 2022
A Cloud Native Buildpack that contributes SDKMAN and uses it to install dependencies like the Java Virtual Machine

gcr.io/paketo-buildpacks/sdkman A Cloud Native Buildpack that contributes SDKMAN and uses it to install dependencies like the Java Virtual Machine. Be

Jan 8, 2022
A Cloud Native Buildpack that provides the Open Liberty runtime

gcr.io/paketo-buildpacks/open-liberty The Paketo Open Liberty Buildpack is a Cloud Native Buildpack that contributes Open Liberty for Java EE support.

Dec 21, 2022
cloneMAP: cloud-native Multi-Agent Platform
 cloneMAP: cloud-native Multi-Agent Platform

cloneMAP: cloud-native Multi-Agent Platform cloneMAP is a multi-agent platform (MAP) that is designed to run in a cloud environment based on Kubernete

Nov 18, 2022
A Cloud Native Buildpack that contributes the Syft CLI which can be used to generate SBoM information

gcr.io/paketo-buildpacks/syft The Paketo Syft Buildpack is a Cloud Native Buildpack that contributes the Syft CLI which can be used to generate SBoM i

Dec 14, 2022
Next generation distributed, event-driven, parallel config management!
 Next generation distributed, event-driven, parallel config management!

mgmt: next generation config management! About: Mgmt is a real-time automation tool. It is familiar to existing configuration management software, but

Dec 26, 2022
JuiceFS is a distributed POSIX file system built on top of Redis and S3.
 JuiceFS is a distributed POSIX file system built on top of Redis and S3.

JuiceFS is an open-source POSIX file system built on top of Redis and object storage (e.g. Amazon S3), designed and optimized for cloud native environ

Jan 2, 2023
a high-performance, POSIX-ish Amazon S3 file system written in Go
 a high-performance, POSIX-ish Amazon S3 file system written in Go

Goofys allows you to mount an S3 bucket as a filey system.

Dec 23, 2022
GoDrive: A cloud storage system similar to Dropbox or Google Drive, with resilient
 GoDrive: A cloud storage system similar to Dropbox or Google Drive, with resilient

Cloud Storage Service Author: Marisa Tania, Ryan Tjakrakartadinata Professor: Matthew Malensek See project spec here: https://www.cs.usfca.edu/~mmalen

Dec 7, 2021
Edge Orchestration project is to implement distributed computing between Docker Container enabled devices.
 Edge Orchestration project is to implement distributed computing between Docker Container enabled devices.

Edge Orchestration Introduction The main purpose of Edge Orchestration project is to implement distributed computing between Docker Container enabled

Dec 17, 2021
Kubernetes Native Edge Computing Framework (project under CNCF)
 Kubernetes Native Edge Computing Framework (project under CNCF)

KubeEdge KubeEdge is built upon Kubernetes and extends native containerized application orchestration and device management to hosts at the Edge. It c

Jan 1, 2023
🦖 Streaming-Serverless Framework for Low-latency Edge Computing applications, running atop QUIC protocol, engaging 5G technology.
 🦖 Streaming-Serverless Framework for Low-latency Edge Computing applications, running atop QUIC protocol, engaging 5G technology.

YoMo YoMo is an open-source Streaming Serverless Framework for building Low-latency Edge Computing applications. Built atop QUIC Transport Protocol an

Dec 29, 2022
a small form factor OpenShift/Kubernetes optimized for edge computing

Microshift Microshift is OpenShift1 Kubernetes in a small form factor and optimized for edge computing. Edge devices deployed out in the field pose ve

Dec 29, 2022