GithubHelp home page GithubHelp logo

kubeedge / edgemesh Goto Github PK

View Code? Open in Web Editor NEW
251.0 251.0 128.0 36.81 MB

Simplified network and services for edge applications

Home Page: https://edgemesh.netlify.app/

License: Apache License 2.0

Dockerfile 0.47% Go 78.76% Makefile 1.13% Shell 15.64% Smarty 4.00%

edgemesh's Introduction

KubeEdge

Go Report Card LICENSE Releases CII Best Practices

English | 简体中文

KubeEdge is built upon Kubernetes and extends native containerized application orchestration and device management to hosts at the Edge. It consists of cloud part and edge part, provides core infrastructure support for networking, application deployment and metadata synchronization between cloud and edge. It also supports MQTT which enables edge devices to access through edge nodes.

With KubeEdge it is easy to get and deploy existing complicated machine learning, image recognition, event processing and other high level applications to the Edge. With business logic running at the Edge, much larger volumes of data can be secured & processed locally where the data is produced. With data processed at the Edge, the responsiveness is increased dramatically and data privacy is protected.

KubeEdge is an incubation-level hosted project by the Cloud Native Computing Foundation (CNCF). KubeEdge incubation announcement by CNCF.

Advantages

  • Kubernetes-native support: Managing edge applications and edge devices in the cloud with fully compatible Kubernetes APIs.
  • Cloud-Edge Reliable Collaboration: Ensure reliable messages delivery without loss over unstable cloud-edge network.
  • Edge Autonomy: Ensure edge nodes run autonomously and the applications in edge run normally, when the cloud-edge network is unstable or edge is offline and restarted.
  • Edge Devices Management: Managing edge devices through Kubernetes native APIs implemented by CRD.
  • Extremely Lightweight Edge Agent: Extremely lightweight Edge Agent(EdgeCore) to run on resource constrained edge.

How It Works

KubeEdge consists of cloud part and edge part.

Architecture

In the Cloud

  • CloudHub: a web socket server responsible for watching changes at the cloud side, caching and sending messages to EdgeHub.
  • EdgeController: an extended kubernetes controller which manages edge nodes and pods metadata so that the data can be targeted to a specific edge node.
  • DeviceController: an extended kubernetes controller which manages devices so that the device metadata/status data can be synced between edge and cloud.

On the Edge

  • EdgeHub: a web socket client responsible for interacting with Cloud Service for the edge computing (like Edge Controller as in the KubeEdge Architecture). This includes syncing cloud-side resource updates to the edge, and reporting edge-side host and device status changes to the cloud.
  • Edged: an agent that runs on edge nodes and manages containerized applications.
  • EventBus: a MQTT client to interact with MQTT servers (mosquitto), offering publish and subscribe capabilities to other components.
  • ServiceBus: an HTTP client to interact with HTTP servers (REST), offering HTTP client capabilities to components of cloud to reach HTTP servers running at edge.
  • DeviceTwin: responsible for storing device status and syncing device status to the cloud. It also provides query interfaces for applications.
  • MetaManager: the message processor between edged and edgehub. It is also responsible for storing/retrieving metadata to/from a lightweight database (SQLite).

Kubernetes compatibility

Kubernetes 1.20 Kubernetes 1.21 Kubernetes 1.22 Kubernetes 1.23 Kubernetes 1.24 Kubernetes 1.25 Kubernetes 1.26 Kubernetes 1.27 Kubernetes 1.28
KubeEdge 1.12 - - - - - -
KubeEdge 1.13 + - - - - -
KubeEdge 1.14 + + - - - -
KubeEdge 1.15 + + + + - -
KubeEdge 1.16 + + + + + -
KubeEdge HEAD (master) + + + + + +

Key:

  • KubeEdge and the Kubernetes version are exactly compatible.
  • + KubeEdge has features or API objects that may not be present in the Kubernetes version.
  • - The Kubernetes version has features or API objects that KubeEdge can't use.

Guides

Get start with this doc.

See our documentation on kubeedge.io for more details.

To learn deeply about KubeEdge, try some examples on examples.

Roadmap

Meeting

Regular Community Meeting:

Resources:

Contact

If you need support, start with the troubleshooting guide, and work your way through the process that we've outlined.

If you have questions, feel free to reach out to us in the following ways:

Contributing

If you're interested in being a contributor and want to get involved in developing the KubeEdge code, please see CONTRIBUTING for details on submitting patches and the contribution workflow.

Security

Security Audit

A third party security audit of KubeEdge has been completed in July 2022. Additionally, the KubeEdge community completed an overall system security analysis of KubeEdge. The detailed reports are as follows.

Reporting security vulnerabilities

We encourage security researchers, industry organizations and users to proactively report suspected vulnerabilities to our security team ([email protected]), the team will help diagnose the severity of the issue and determine how to address the issue as soon as possible.

For further details please see Security Policy for our security process and how to report vulnerabilities.

License

KubeEdge is under the Apache 2.0 license. See the LICENSE file for details.

edgemesh's People

Contributors

cl2017 avatar daixiang0 avatar gy95 avatar huapox avatar icarus9913 avatar ideameshdyx avatar jiaweigithub avatar jidalong avatar jinglina avatar jooks-me avatar just1n-wang avatar kevin-wangzefeng avatar khalid-huang avatar kubeedge-bot avatar lvchenggang avatar lynxcat avatar muxuelan avatar nkdyx avatar pengbinbin1 avatar poorunga avatar sdghchj avatar seveirbian avatar siredmar avatar ssen85 avatar wackxu avatar yz271544 avatar zboishere avatar zhu733756 avatar zy123454321yz avatar zzr93 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

edgemesh's Issues

CI e2e test support

What would you like to be added/modified:
I would like to add a e2e test framework for edgemesh and support ci e2e.

Why is this needed:
Through this, we can have a means to know whether it will affect existing functions when making changes or new features, and at the same time standardize the development process

CI e2e improvement

In the current CI e2e process, there are some bugs we need to fix and improvement we need to do.

  • If the creation of a pod fails, the creation request is not sent again, and the e2e test will failed. It needs to be optimized to add a retry if the creation of a pod fails. https://github.com/kubeedge/edgemesh/runs/3607557974?check_suite_focus=true #110
  • Use docker to simulate more nodes to do more tests.
  • Delete the hostport in the e2e test code, because we no longer have hostport restrictions。 https://github.com/kubeedge/edgemesh/blob/main/tests/e2e/k8s/tools.go#L136
  • Try to using the kubectl log on the edge to fetch the log ranther than using docker logs in the script code
  • CI e2e retry times is 20, we should set the retry times to 2 or 3
  • CI e2e test support differenct config for edgemesh, such as test open tls and close tls feature both.
  • Use helm to deploy edgemesh in shell bash.
  • Use unity the script in #221 to config kubeedge

Apache Kafka and Edgemesh

OS: ubuntu 20.04.4 LTS
KubeEdge version: v1.7.1
EdgeMesh version: v1.7.0
K8S version:1.9.0

My cluster is:

frapedge00001    Ready    agent,edge   53d   v1.19.3-kubeedge-v1.7.1
fraporion00001   Ready    master       53d   v1.19.12
fraprigel00001   Ready    agent,edge   47d   v1.19.3-kubeedge-v1.7.1

I'm running an Apache Kafka broker in the cloud node and I wanted to have a second one running on the edge node. I deployed it successfully but I receive some errors from the edgemesh-agent when the broker tries to connect to zookeeper:

W0830 15:23:03.056106       1 proxy.go:45] get protocol from sock error: protocol: client is not supported yet
I0830 15:24:25.769042       1 dns.go:73] dns server parse zoo1.default. ip 10.103.159.182
I0830 15:24:25.778393       1 proxy.go:37] clusterIP: 10.103.159.182, servicePort: 2181
W0830 15:24:25.778421       1 proxy.go:45] get protocol from sock error: protocol: client is not supported yet
I0830 15:24:27.464858       1 proxy.go:37] clusterIP: 10.103.159.182, servicePort: 2181
W0830 15:24:27.464896       1 proxy.go:45] get protocol from sock error: protocol: client is not supported yet
I0830 15:24:28.760372       1 proxy.go:37] clusterIP: 10.103.159.182, servicePort: 2181
W0830 15:24:28.760402       1 proxy.go:45] get protocol from sock error: protocol: client is not supported yet
I0830 15:24:29.927760       1 proxy.go:37] clusterIP: 10.103.159.182, servicePort: 2181
W0830 15:24:29.927791       1 proxy.go:45] get protocol from sock error: protocol: client is not supported yet
I0830 15:24:31.299092       1 proxy.go:37] clusterIP: 10.103.159.182, servicePort: 2181
W0830 15:24:31.299123       1 proxy.go:45] get protocol from sock error: protocol: client is not supported yet
I0830 15:24:33.008408       1 proxy.go:37] clusterIP: 10.103.159.182, servicePort: 2181
W0830 15:24:33.008440       1 proxy.go:45] get protocol from sock error: protocol: client is not supported yet
I0830 15:24:35.046741       1 proxy.go:37] clusterIP: 10.103.159.182, servicePort: 2181
W0830 15:24:35.046772       1 proxy.go:45] get protocol from sock error: protocol: client is not supported yet
I0830 15:24:36.403169       1 proxy.go:37] clusterIP: 10.103.159.182, servicePort: 2181
W0830 15:24:36.403200       1 proxy.go:45] get protocol from sock error: protocol: client is not supported yet
I0830 15:24:38.363474       1 proxy.go:37] clusterIP: 10.103.159.182, servicePort: 2181
W0830 15:24:38.363506       1 proxy.go:45] get protocol from sock error: protocol: client is not supported yet

Any ideas on this issue? Maybe the proxy doesn't support the specific communication protocol?

More Explicit Intro

What would you like to be added/modified:

Change "At the edge node, close edgeMesh module, open metaServer module, and restart edgecore" to "At the edge node, close edgeMesh module if it exists, open metaServer module, and restart edgecore" or some what.
image

Why is this needed:

Since the edgemesh module in edgecore has been removed, there is necessary to make the declaration more clear.
image

edgemesh-agent-cloud cannnot work nomally

What happened:
when I deploy edgemesh follow the README, the daemonset.app of edgemesh-agent-cloud cannot work normally. It shows DESIRED 0, it is different from README.

What you expected to happen:
edgemesh-agent-cloud work nomally
How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

  • EdgeMesh version: v1.8.0

  • Kubernetes version (use kubectl version):Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:20:10Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}
    Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.17", GitCommit:"f3abc15296f3a3f54e4ee42e830c61047b13895f", GitTreeState:"clean", BuildDate:"2021-01-13T13:13:00Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

  • KubeEdge version(e.g. cloudcore --version and edgecore --version): v1.8.0

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu): vmware
    • OS (e.g. cat /etc/os-release): centos 7.9
    • Kernel (e.g. uname -a): Linux ke-cloud 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

EdgeMesh-agent deployment failure on Raspberry Pi 4 (ARM based CPU)

What happened:

edgemesh-agent cannot be deployed on Raspberry Pi 4.

pi@raspberrypi:~ $ docker ps -a

CONTAINER ID   IMAGE                     COMMAND            CREATED         STATUS                     PORTS     NAMES

abbba6511322   kubeedge/edgemesh-agent   "edgemesh-agent"   2 minutes ago   Exited (1) 2 minutes ago             k8s_edgemesh-agent_edgemesh-agent-edge-7bbsm_kubeedge_1dce335a-e6a7-4b91-b2b3-e11d97c395b8_92

a78a927b7ec2   kubeedge/pause-arm:3.1    "/pause"           8 hours ago     Up 8 hours                           k8s_POD_edgemesh-agent-edge-7bbsm_kubeedge_1dce335a-e6a7-4b91-b2b3-e11d97c395b8_0

Check docker container through docker logs

pi@raspberrypi:~ $ docker logs abbba6511322

standard_init_linux.go:228: exec user process caused: exec format error

What you expected to happen:

EdgeMesh deployment complete without any error

root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud# kubectl get all -n kubeedge -o wide

NAME                                   READY   STATUS    RESTARTS   AGE     IP              NODE                NOMINATED NODE   READINESS GATES
pod/edgemesh-agent-edge-7bbsm          1/1     Running     57         5h10m   192.168.0.86    raspberrypi         <none>           <none>
pod/edgemesh-agent-edge-rbcrv          1/1     Running   0          6h6m    192.168.0.206   default-edge-node   <none>           <none>
pod/edgemesh-server-7bdbcfc7b5-hf4ds   1/1     Running   0          36s     <none>          cloud-node          <none>           <none>

NAME                                  DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE    CONTAINERS       IMAGES                           SELECTOR
daemonset.apps/edgemesh-agent-cloud   0         0         0       0            0           <none>          6h7m   edgemesh-agent   kubeedge/edgemesh-agent:latest   k8s-app=kubeedge,kubeedge=edgemesh-agent
daemonset.apps/edgemesh-agent-edge    2         2         2       2            2           <none>          6h6m   edgemesh-agent   kubeedge/edgemesh-agent:latest   k8s-app=kubeedge,kubeedge=edgemesh-agent

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS        IMAGES                            SELECTOR
deployment.apps/edgemesh-server   1/1     1            1           6h44m   edgemesh-server   kubeedge/edgemesh-server:latest   k8s-app=kubeedge,kubeedge=edgemesh-server

NAME                                         DESIRED   CURRENT   READY   AGE     CONTAINERS        IMAGES                            SELECTOR
replicaset.apps/edgemesh-server-7bdbcfc7b5   1         1         1       6h44m   edgemesh-server   kubeedge/edgemesh-server:latest   k8s-app=kubeedge,kubeedge=edgemesh-server,pod-template-hash=7bdbcfc7b5

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

  1. Deploy a k8s cluster through kubeadm

  2. Deploy a KubeEdge cluster (Binary Method)

    • master node: k8s master + KubeEdge cloud
    • edge node 1: KubeEdge edge node (intel CPU PC)
    • edge node 2: KubeEdge edge node (arm CPU Raspberry Pi 4)
  3. Deploy EdgeMesh through kubectl apply -f by the Official Document

Anything else we need to know?:

command:

kubectl get all -n kubeedge -o wide
root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud# kubectl get all -n kubeedge -o wide
NAME                                   READY   STATUS    RESTARTS   AGE     IP              NODE                NOMINATED NODE   READINESS GATES
pod/edgemesh-agent-edge-7bbsm          0/1     Error     57         5h10m   192.168.0.86    raspberrypi         <none>           <none>
pod/edgemesh-agent-edge-rbcrv          1/1     Running   0          6h6m    192.168.0.206   default-edge-node   <none>           <none>
pod/edgemesh-server-7bdbcfc7b5-hf4ds   0/1     Pending   0          36s     <none>          cloud-node          <none>           <none>

NAME                                  DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE    CONTAINERS       IMAGES                           SELECTOR
daemonset.apps/edgemesh-agent-cloud   0         0         0       0            0           <none>          6h7m   edgemesh-agent   kubeedge/edgemesh-agent:latest   k8s-app=kubeedge,kubeedge=edgemesh-agent
daemonset.apps/edgemesh-agent-edge    2         2         1       2            1           <none>          6h6m   edgemesh-agent   kubeedge/edgemesh-agent:latest   k8s-app=kubeedge,kubeedge=edgemesh-agent

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS        IMAGES                            SELECTOR
deployment.apps/edgemesh-server   0/1     1            0           6h44m   edgemesh-server   kubeedge/edgemesh-server:latest   k8s-app=kubeedge,kubeedge=edgemesh-server

NAME                                         DESIRED   CURRENT   READY   AGE     CONTAINERS        IMAGES                            SELECTOR
replicaset.apps/edgemesh-server-7bdbcfc7b5   1         1         0       6h44m   edgemesh-server   kubeedge/edgemesh-server:latest   k8s-app=kubeedge,kubeedge=edgemesh-server,pod-template-hash=7bdbcfc7b5

Environment:

  • EdgeMesh version: main branch

    root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# git checkout
    
    M	build/server/edgemesh/05-configmap.yaml
    Your branch is up to date with 'origin/main'.

    (2021/09/17 18:46)

  • Kubernetes version (use kubectl version):

    root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# kubectl version
    
    Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.14", GitCommit:"0fd2b5afdfe3134d6e1531365fdb37dd11f54d1c", GitTreeState:"clean", BuildDate:"2021-08-11T18:07:41Z", GoVersion:"go1.15.15", Compiler:"gc", Platform:"linux/amd64"}
    
    Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.14", GitCommit:"0fd2b5afdfe3134d6e1531365fdb37dd11f54d1c", GitTreeState:"clean", BuildDate:"2021-08-11T18:02:17Z", GoVersion:"go1.15.15", Compiler:"gc", Platform:"linux/amd64"}
  • KubeEdge version(e.g. cloudcore --version and edgecore --version):

    cloudcore on k8s master node

    root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# cloudcore --version
    
    KubeEdge v1.8.0-beta.0.81+149aa721b82ae9

    The intel CPU based PC

    charlie-edge@charlieedge-CM1745:~$ edgecore --version
    
    KubeEdge v1.8.0-beta.0.81+149aa721b82ae9

    The ARM CPU based Raspberry Pi 4

    pi@raspberrypi:~ $ edgecore --version
    
    KubeEdge v1.8.0-beta.0.91+29905c6704b6e9
  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
      root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# lscpu
      
        Architecture:                    x86_64
        CPU op-mode(s):                  32-bit, 64-bit
        Byte Order:                      Little Endian
        Address sizes:                   39 bits physical, 48 bits virtual
        CPU(s):                          6
        On-line CPU(s) list:             0-5
        Thread(s) per core:              1
        Core(s) per socket:              6
        Socket(s):                       1
        NUMA node(s):                    1
        Vendor ID:                       GenuineIntel
        CPU family:                      6
        Model:                           158
        Model name:                      Intel(R) Core(TM) i5-8500 CPU @ 3.00GHz
        Stepping:                        10
        CPU MHz:                         887.468
        CPU max MHz:                     4100.0000
        CPU min MHz:                     800.0000
        BogoMIPS:                        6000.00
        Virtualization:                  VT-x
        L1d cache:                       192 KiB
        L1i cache:                       192 KiB
        L2 cache:                        1.5 MiB
        L3 cache:                        9 MiB
        NUMA node0 CPU(s):               0-5
        Vulnerability Itlb multihit:     KVM: Mitigation: VMX disabled
        Vulnerability L1tf:              Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled
        Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT disabled
        Vulnerability Meltdown:          Mitigation; PTI
        Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
        Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
        Vulnerability Spectre v2:        Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling
        Vulnerability Srbds:             Mitigation; Microcode
        Vulnerability Tsx async abort:   Mitigation; Clear CPU buffers; SMT disabled
        Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constan
                                        t_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16
                                        xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd
                                        ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt in
                                        tel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
    • OS (e.g. cat /etc/os-release):
      root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# cat /etc/os-release
      
        NAME="Ubuntu"
        VERSION="20.04.3 LTS (Focal Fossa)"
        ID=ubuntu
        ID_LIKE=debian
        PRETTY_NAME="Ubuntu 20.04.3 LTS"
        VERSION_ID="20.04"
        HOME_URL="https://www.ubuntu.com/"
        SUPPORT_URL="https://help.ubuntu.com/"
        BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
        PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
        VERSION_CODENAME=focal
        UBUNTU_CODENAME=focal
    • Kernel (e.g. uname -a):
      root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# uname -a
      
      Linux charliecloud-ASUSPRO-D340MC-C-S340MC 5.11.0-34-generic #36~20.04.1-Ubuntu SMP Fri Aug 27 08:06:32 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
    • Go version (e.g. go version):
      root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# go version
      
      go version go1.17 linux/amd64
    • Others:
  • Edge nodes Environment:
    1. PC (intel CPU)
    • edgecore version (e.g. edgecore --version):
      charlie-edge@charlieedge-CM1745:~$ edgecore --version
      
      KubeEdge v1.8.0-beta.0.81+149aa721b82ae9
    • Hardware configuration (e.g. lscpu):
      charlie-edge@charlieedge-CM1745:~$ lscpu
      
      Architecture:                    x86_64
      CPU op-mode(s):                  32-bit, 64-bit
      Byte Order:                      Little Endian
      Address sizes:                   48 bits physical, 48 bits virtual
      CPU(s):                          4
      On-line CPU(s) list:             0-3
      Thread(s) per core:              2
      Core(s) per socket:              2
      Socket(s):                       1
      NUMA node(s):                    1
      Vendor ID:                       AuthenticAMD
      CPU family:                      21
      Model:                           16
      Model name:                      AMD A8-5500 APU with Radeon(tm) HD Graphics
      Stepping:                        1
      Frequency boost:                 enabled
      CPU MHz:                         1400.000
      CPU max MHz:                     3200.0000
      CPU min MHz:                     1400.0000
      BogoMIPS:                        6400.57
      Virtualization:                  AMD-V
      L1d cache:                       32 KiB
      L1i cache:                       128 KiB
      L2 cache:                        4 MiB
      NUMA node0 CPU(s):               0-3
      Vulnerability Itlb multihit:     Not affected
      Vulnerability L1tf:              Not affected
      Vulnerability Mds:               Not affected
      Vulnerability Meltdown:          Not affected
      Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled v
                                      ia prctl and seccomp
      Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user
                                      pointer sanitization
      Vulnerability Spectre v2:        Mitigation; Full AMD retpoline, STIBP disabled,
                                      RSB filling
      Vulnerability Srbds:             Not affected
      Vulnerability Tsx async abort:   Not affected
      Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtr
                                      r pge mca cmov pat pse36 clflush mmx fxsr sse s
                                      se2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtsc
                                      p lm constant_tsc rep_good nopl nonstop_tsc cpu
                                      id extd_apicid aperfmperf pni pclmulqdq monitor
                                      ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave 
                                      avx f16c lahf_lm cmp_legacy svm extapic cr8_leg
                                      acy abm sse4a misalignsse 3dnowprefetch osvw ib
                                      s xop skinit wdt lwp fma4 tce nodeid_msr tbm to
                                      poext perfctr_core perfctr_nb cpb hw_pstate ssb
                                      d vmmcall bmi1 arat npt lbrv svm_lock nrip_save
                                      tsc_scale vmcb_clean flushbyasid decodeassists
                                      pausefilter pfthreshold
    • OS (e.g. cat /etc/os-release):
      charlie-edge@charlieedge-CM1745:~$ cat /etc/os-release
      
      NAME="Ubuntu"
      VERSION="20.04.2 LTS (Focal Fossa)"
      ID=ubuntu
      ID_LIKE=debian
      PRETTY_NAME="Ubuntu 20.04.2 LTS"
      VERSION_ID="20.04"
      HOME_URL="https://www.ubuntu.com/"
      SUPPORT_URL="https://help.ubuntu.com/"
      BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
      PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
      VERSION_CODENAME=focal
      UBUNTU_CODENAME=focal
    • Kernel (e.g. uname -a):
      charlie-edge@charlieedge-CM1745:~$ uname -a
      
      Linux charlieedge-CM1745 5.11.0-34-generic #36~20.04.1-Ubuntu SMP Fri Aug 27 08:06:32 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
    • Go version (e.g. go version):
      charlie-edge@charlieedge-CM1745:~$ go version
      
      go version go1.17 linux/amd64
    • Others:
    1. Raspberry Pi (arm CPU)
    • edgecore version (e.g. edgecore --version):
      pi@raspberrypi:~ $ edgecore --version
      
      KubeEdge v1.8.0-beta.0.91+29905c6704b6e9
    • Hardware configuration (e.g. lscpu):
      pi@raspberrypi:~ $ lscpu
      
      Architecture:        armv7l
      Byte Order:          Little Endian
      CPU(s):              4
      On-line CPU(s) list: 0-3
      Thread(s) per core:  1
      Core(s) per socket:  4
      Socket(s):           1
      Vendor ID:           ARM
      Model:               3
      Model name:          Cortex-A72
      Stepping:            r0p3
      CPU max MHz:         1500.0000
      CPU min MHz:         600.0000
      BogoMIPS:            108.00
      Flags:               half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
    • OS (e.g. cat /etc/os-release):
      pi@raspberrypi:~ $ cat /etc/os-release
      
      PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
      NAME="Raspbian GNU/Linux"
      VERSION_ID="10"
      VERSION="10 (buster)"
      VERSION_CODENAME=buster
      ID=raspbian
      ID_LIKE=debian
      HOME_URL="http://www.raspbian.org/"
      SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
      BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
    • Kernel (e.g. uname -a):
      pi@raspberrypi:~ $ uname -a
      
      Linux raspberrypi 5.10.60-v7l+ #1449 SMP Wed Aug 25 15:00:44 BST 2021 armv7l GNU/Linux
    • Go version (e.g. go version):
      pi@raspberrypi:~ $ go version
      
      go version go1.17 linux/arm
    • Others:

edgemesh-agent always pending

What happened:
When edgemesh is deployed, edgemesh agent is always in pending state

[root@k8s-master edgemesh-agent]# kubectl get po -n kubeedge
NAME                               READY   STATUS    RESTARTS   AGE
edgemesh-agent-cloud-fgw8c         1/1     Running   0          80m
edgemesh-agent-cloud-nmbcb         1/1     Running   0          80m
edgemesh-agent-edge-4pbpd          0/1     Pending   0          63m
edgemesh-agent-edge-69gpr          0/1     Pending   0          63m
edgemesh-server-5f4d8b8b5b-fv9bj   1/1     Running   0          6h53m

Edge node to view edgecore status
image

image

What you expected to happen:

I hope to solve the above problems

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

Anything else we need to know?:

Environment:

  • EdgeMesh version: edgemesh:v1.8

  • Kubernetes version (use kubectl version):v1.19.3

  • KubeEdge version(e.g. cloudcore --version and edgecore --version):kubeedge-v1.7.2

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):

    • Architecture: x86_64
      CPU op-mode(s): 32-bit, 64-bit
      Byte Order: Little Endian
      CPU(s): 4
      On-line CPU(s) list: 0-3
      Thread(s) per core: 1
      Core(s) per socket: 1
      Socket(s): 4
      NUMA node(s): 1
      Vendor ID: GenuineIntel
      CPU family: 6
      Model: 61
      Model name: Intel Core Processor (Broadwell, IBRS)
      Stepping: 2
      CPU MHz: 2095.148
      BogoMIPS: 4190.29
      Hypervisor vendor: KVM
      Virtualization type: full
      L1d cache: 32K
      L1i cache: 32K
      L2 cache: 4096K
      NUMA node0 CPU(s): 0-3
      Flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm 3dnowprefetch ssbd ibrs ibpb fsgsbase bmi1 hle avx2 smep bmi2 erms rtm rdseed adx smap xsaveopt md_clear spec_ctrl

    • OS (e.g. cat /etc/os-release):

    • NAME="CentOS Linux"
      VERSION="7 (Core)"
      ID="centos"
      ID_LIKE="rhel fedora"
      VERSION_ID="7"
      PRETTY_NAME="CentOS Linux 7 (Core)"
      ANSI_COLOR="0;31"
      CPE_NAME="cpe:/o:centos:centos:7"
      HOME_URL="https://www.centos.org/"
      BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

- Kernel (e.g. `uname -a`):
- Linux k8s-master 3.10.0-1160.15.2.el7.x86_64 #1 SMP Wed Feb 3 15:06:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
- Go version (e.g. `go version`):
- Others:
-
Edge nodes Environment:
- edgecore version (e.g. `edgecore --version`): v1.7.2
- Hardware configuration (e.g. `lscpu`):
- Architecture:          x86_64

CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 4
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 61
Model name: Intel Core Processor (Broadwell, IBRS)
Stepping: 2
CPU MHz: 2095.148
BogoMIPS: 4190.29
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
NUMA node0 CPU(s): 0-3
Flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm 3dnowprefetch ssbd ibrs ibpb fsgsbase bmi1 hle avx2 smep bmi2 erms rtm rdseed adx smap xsaveopt md_clear spec_ctrl

- OS (e.g. `cat /etc/os-release`):
- NAME="CentOS Linux"

VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

- Kernel (e.g. `uname -a`):
- Linux ke-edge1 3.10.0-1160.15.2.el7.x86_64 #1 SMP Wed Feb 3 15:06:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
- Go version (e.g. `go version`):
- Others:

Demo: cross-edge-cloud communication between pods

KubeEdge community meeting Aug 18th, 2021 (Europe Time)

Today my topic is EdgeMesh: Cross-edge-cloud communication between pods demo. And I am here to make a brief summary of what was said at the meeting.

My Cluster Environment:

image

k8s-master is a k8s control-plane and also a k8s worker. k8s-node1 is a k8s worker. ke-edge1 and ke-edge2 are edge nodes of kubeedge, and they access the Internet through a NAT.

[root@k8s-master ~]# kubectl get nodes
NAME         STATUS   ROLES           AGE     VERSION
k8s-master   Ready    master,worker   3d18h   v1.18.20
k8s-node1    Ready    worker          3d18h   v1.18.20
ke-edge1     Ready    agent,edge      25h     v1.19.3-kubeedge-v1.7.2
ke-edge2     Ready    agent,edge      25h     v1.19.3-kubeedge-v1.7.2

edgemesh-server is deployed on the cloud node, and has a public IP. edgemesh-agent is divided into two parts: cloud and edge.

[root@k8s-master ~]# kubectl get all -n kubeedge
NAME                                   READY   STATUS    RESTARTS   AGE
pod/edgemesh-agent-cloud-dkwwc         1/1     Running   0          74m
pod/edgemesh-agent-cloud-rl6pq         1/1     Running   0          74m
pod/edgemesh-agent-edge-jr5xs          1/1     Running   0          23h
pod/edgemesh-agent-edge-kbzhh          1/1     Running   0          23h
pod/edgemesh-server-7f97d77469-dml4j   1/1     Running   0          83m

NAME                                  DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/edgemesh-agent-cloud   2         2         2       2            2           <none>          74m
daemonset.apps/edgemesh-agent-edge    2         2         2       2            2           <none>          23h

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/edgemesh-server   1/1     1            1           83m

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/edgemesh-server-7f97d77469   1         1         1       83m

My Test Case

image

tcp-echo-edge and busybox-edge are deployed in the edgezone namespace. tcp-echo-cloud and busybox-cloud are deployed in the cloudzone namespace. busybox-edge is used to access tcp-echo-cloud-svc. busybox-cloud is used to access tcp-echo-edge-svc.

[root@k8s-master ~]# kubectl get all -n cloudzone
NAME                      READY   STATUS    RESTARTS   AGE
pod/busybox-sleep-cloud   1/1     Running   0          23m
pod/tcp-echo-cloud        1/1     Running   0          23m

NAME                         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/tcp-echo-cloud-svc   ClusterIP   10.98.233.235   <none>        2701/TCP   23m

[root@k8s-master ~]# kubectl get all -n edgezone
NAME                     READY   STATUS    RESTARTS   AGE
pod/busybox-sleep-edge   1/1     Running   7          23h
pod/tcp-echo-edge        1/1     Running   0          24h

NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/tcp-echo-edge-svc   ClusterIP   10.106.241.223   <none>        2701/TCP   24h

Start Playing

Cloud access edge

[root@k8s-master ~]# kubectl exec -it pod/busybox-sleep-cloud sh -n cloudzone
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
/ # telnet tcp-echo-edge-svc.edgezone 2701
Welcome, you are connected to node ke-edge1.
Running on Pod tcp-echo-edge.
In namespace edgezone.
With IP address 172.17.0.2.
Service default.
I'm cloud busybox
I'm cloud busybox

Edge access cloud

[root@ke-edge1 ~]# docker exec -it b4f1820ba1f6 sh
/ # telnet tcp-echo-cloud-svc.cloudzone 2701
Welcome, you are connected to node k8s-master.
Running on Pod tcp-echo-cloud.
In namespace cloudzone.
With IP address 10.244.0.7.
Service default.
I'm edge busybox
I'm edge busybox

Traffic forwarding path

hole-punching successful: busybox --> edgemesh-agent(1) --> edgemesh-agent(2) --> tcp-echo
hole-punching failure: busybox --> edgemesh-agent(1) --> edgemesh-server(reley) --> edgemesh-agent(2) --> tcp-echo

All yaml files in PR: #57 🐱‍🏍

Add notification

What would you like to be added/modified:

When is deploy edgemesh-server, it always shows a pending status. And I finally find that the default configuration in deployment.yaml requests the edgemesh-server to be deployed to a node named "cloud-node", but i do not have it. I know I need to modify this value to my cloud node name, but I think it will be better to add a notification.
image

Why is this needed:

Could not resolve host: hostname-svc.default (Failed to watch *v1alpha3.DestinationRule:)

OS: ubuntu 18.04.4 LTS
KubeEdge version: v1.7.1
EdgeMesh version: v1.7.0
K8S version:1.9.0

Problem:

root@edgenode:~# curl hostname-svc.default:12345 -v
* Rebuilt URL to: hostname-svc.default:12345/
* Could not resolve host: hostname-svc.default
* Closing connection 0
curl: (6) Could not resolve host: hostname-svc.default

When I do this: docker logs -f "edgemesh agent container id"
It returns an error "Failed to watch *v1alpha3.DestinationRule" like follows:

root@edgenode:~# docker logs -f 2b35df37d825
2021/08/13 02:07:31 INFO: Install client plugin, protocol: rest
2021/08/13 02:07:31 INFO: Installed service discovery plugin: edge
I0813 02:07:31.181969       1 server.go:54] Version: v1.7.1-9+2b655fcbc51f38
I0813 02:07:31.181988       1 server.go:88] [1] New informers manager
I0813 02:07:31.182448       1 server.go:95] [2] Register beehive modules
I0813 02:07:31.182722       1 module.go:34] Module edgedns registered successfully
I0813 02:07:31.190298       1 module.go:34] Module edgeproxy registered successfully
W0813 02:07:31.190381       1 module.go:37] Module edgegateway is disabled, do not register
I0813 02:07:31.190438       1 privkey.go:34] Private key does not exist, generate a new one
I0813 02:07:31.266883       1 module.go:34] Module tunnelagent registered successfully
I0813 02:07:31.267035       1 server.go:104] [3] Install go-chassis plugins
I0813 02:07:31.267146       1 log.go:181] DEBUG: Installed strategy plugin: [RoundRobin].
I0813 02:07:31.267195       1 log.go:181] DEBUG: Installed strategy plugin: [Random].
I0813 02:07:31.267222       1 log.go:181] DEBUG: Installed strategy plugin: [ConsistentHash].
I0813 02:07:31.267263       1 log.go:181] DEBUG: ConfigurationFactory Initiated
I0813 02:07:31.267291       1 log.go:181] INFO: Configuration files: []
I0813 02:07:31.267334       1 log.go:181] WARN: empty configurtion from [FileSource]
I0813 02:07:31.267371       1 log.go:181] INFO: invoke dynamic handler:FileSource
I0813 02:07:31.267410       1 log.go:181] INFO: archaius init success
I0813 02:07:31.267444       1 server.go:109] [4] Start informers manager
I0813 02:07:31.268402       1 log.go:181] INFO: create new watcher
E0813 02:07:31.294654       1 reflector.go:127] /code/common/informers/informers.go:87: Failed to watch *v1alpha3.DestinationRule: failed to list *v1alpha3.DestinationRule: no kind "DestinationrulList" is registered for version "networking.istio.io/v1alpha3" in scheme "istio.io/client-go/pkg/clientset/versioned/scheme/register.gen.go:30"
E0813 02:07:31.294784       1 reflector.go:127] istio.io/client-go/pkg/informers/externalversions/factory.gen.go:116: Failed to watch *v1alpha3.DestinationRule: failed to list *v1alpha3.DestinationRule: no kind "DestinationrulList" is registered for version "networking.istio.io/v1alpha3" in scheme "istio.io/client-go/pkg/clientset/versioned/scheme/register.gen.go:30"
E0813 02:07:32.327858       1 reflector.go:127] istio.io/client-go/pkg/informers/externalversions/factory.gen.go:116: Failed to watch *v1alpha3.DestinationRule: failed to list *v1alpha3.DestinationRule: no kind "DestinationrulList" is registered for version "networking.istio.io/v1alpha3" in scheme "istio.io/client-go/pkg/clientset/versioned/scheme/register.gen.go:30"

My yaml : kubectl apply -f examples/hostname.yaml

apiVersion: v1
kind: Pod
metadata:
  name: hostname-edge
  namespace: default
  labels:
    app: hostname-edge
spec:
  nodeName: edgenode
  containers:
    - name: hostname
      image: k8s.gcr.io/serve_hostname:latest
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 9376
          hostPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: hostname-svc
  namespace: default
spec:
  selector:
    app: hostname-edge
  ports:
    - name: http-0
      port: 12345
      protocol: TCP
      targetPort: 9376

curl 127.0.0.1:10550/api/v1/services on edgenode

root@edgenode:~# curl 127.0.0.1:10550/api/v1/services
{"apiVersion":"v1","items":[{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Service\",\"metadata\":{\"annotations\":{},\"name\":\"argo-server\",\"namespace\":\"argo\"},\"spec\":{\"ports\":[{\"name\":\"web\",\"port\":2746,\"targetPort\":2746}],\"selector\":{\"app\":\"argo-server\"}}}\n"},"creationTimestamp":"2021-07-30T06:47:54Z","managedFields":[{"apiVersion":"v1","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:annotations":{".":{},"f:kubectl.kubernetes.io/last-applied-configuration":{}}},"f:spec":{"f:ports":{".":{},"k:{\"port\":2746,\"protocol\":\"TCP\"}":{".":{},"f:name":{},"f:port":{},"f:protocol":{},"f:targetPort":{}}},"f:selector":{".":{},"f:app":{}},"f:sessionAffinity":{},"f:type":{}}},"manager":"kubectl-client-side-apply","operation":"Update","time":"2021-07-30T06:47:54Z"}],"name":"argo-server","namespace":"argo","resourceVersion":"41590887","selfLink":"argo/services/argo-server","uid":"85953948-4514-4973-a614-c035133472ce"},"spec":{"clusterIP":"10.102.174.236",
......

Wrong Websocket Usecase

README asks me to use examples/websocket-pod-svc.yaml to create websocket server, but there is no websocket-pod-svc.yaml in example folder, and only websocket.yaml there.
image
image

'Gateway' doesn't work once EdgeMesh-Ingress-Gateway is deployley firstly

What happened:
Gateway works:

  1. Create new 'Gateway' and 'VirtualService'
  2. Deploy edgemesh-gateway
    image

Gateway fails:

  1. Deploy edgemesh-gateway
  2. Create new 'Gateway' and 'VirtualService'
    image

What you expected to happen:
Once edgemesh-gateway is running, 'Gateway' and 'VirtualService' created later will always work.

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

Anything else we need to know?:

Environment:

  • EdgeMesh version:release-1.7

  • Kubernetes version (use kubectl version):Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.4", GitCommit:"d360454c9bcd1634cf4cc52d1867af5491dc9c5f", GitTreeState:"clean", BuildDate:"2020-11-11T13:17:17Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
    Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:48:36Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

  • KubeEdge version(e.g. cloudcore --version and edgecore --version):cloudcore: release-1.7, edgecore: release-1.7

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

For user explicit specify which services do not need to be hijacked by edgemesh

Hi, Consider adding a label (proxyby=edgemesh) to the service to support the user's declaration of which services do not need to be hijacked by edgemesh.

#66 (comment)

in the kubeedge/edgemesh/agent/pkg/proxy/iptables.go, i try use the LabelSelector: "proxyby!=edgemesh", can filtered services of the not use this label.

	// Other services we want to ignore...
	otherIgnoreServiceList, err := proxier.kubeClient.CoreV1().Services("").List(context.Background(), metav1.ListOptions{LabelSelector: "proxyby!=edgemesh"})
	if err != nil {
		klog.Warningf("get Other ignore service failed: %s", err)
	}
	klog.Infof("filtered service: %d", len(otherIgnoreServiceList.Items))
	if err == nil && otherIgnoreServiceList != nil && len(otherIgnoreServiceList.Items) > 0 {
		for _, item := range otherIgnoreServiceList.Items {
			klog.Infof("ignored not containing proxyby=edgemesh label service: %s", item.Name)
			ignoreRulesIptablesEnsureMap[strings.Join([]string{item.Namespace, item.Name}, ".")] = &item
		}
	}

but, i find some Headless service occurred an error in this line:

			if _, err := proxier.iptables.EnsureRule(utiliptables.Append, rule.table, rule.srcChain, args...); err != nil {
				klog.ErrorS(err, "Failed to ensure ignore rules", "table", rule.table, "srcChain", rule.srcChain, "dstChain", rule.dstChain)
				return
			}

The reason is that in this function, we did not perform special processing on svc.Spec.ClusterIP=="None".

func ignoreRuleByService(svc *corev1.Service) iptablesEnsureInfo {
	var (
		ruleExtraArgs = func(svc *corev1.Service) []string {
			dst := fmt.Sprintf("%s/32", svc.Spec.ClusterIP)  // if svc.Spec.ClusterIP == "None" ???
			return []string{"-d", dst}
		}

		ruleComment = func(svc *corev1.Service) string {
			return fmt.Sprintf("ignore %s.%s service", svc.Name, svc.Namespace)
		}
	)
	return iptablesEnsureInfo{
		table:     utiliptables.TableNAT,
		dstChain:  "RETURN", // return parent chain
		srcChain:  meshRootChain,
		comment:   ruleComment(svc),
		extraArgs: ruleExtraArgs(svc),
	}
}

I have a question. For these headless services, I don't want edgemesh to perform traffic hijacking.
Do I need to use the Endpoints IP corresponding to the Headless service and add it to iptables ignore?

remove hostPort restriction

What would you like to be added/modified:
remove the restriction of hostport when create deployment or daemonset and pod
Why is this needed:
when you create a pod template on kubernetes, you can add hostPort depending on you needs, but in edgemesh, in order to solve service communication cross host, it require add hostPort in pod template.
In addition, two pods associated with one deployment can't be deployed in the same node, because they have the same hostport.
In the feature of cross lan communication, we add tunnel module resolving the service communication without the dependence on hostport, so we need to remove hostport restriction so that guarantee the same experience as kubernetes.

virtual service can not use when transport http data through tcp

What happened:
virtual service can not use when transport http data through tcp
if virtual service associate one more service, the traffic only redirect to the first service
What you expected to happen:
virtual service can work well
How to reproduce it (as minimally and precisely as possible):
create deploymentA contains 3 http serverA
create deploymentB contains 3 http serverB
create serviceA associate 3 http serverA pods
create serviceB associate 3 http serverB pods
create gateway
create virtualservice, pathA redirect traffic to serviceA, pathB redirect traffic to serviceB
Anything else we need to know?:

Environment:

  • EdgeMesh version:

  • 1.7.1

  • Kubernetes version (use kubectl version):

  • 1.20.0

  • KubeEdge version(e.g. cloudcore --version and edgecore --version):

  • 1.7.1

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

Cannot see the iptables EDGE-MESH chain on centos8

What happened:

When edgemesh-agent is running on the centos8 system, we cannot see the EDGE-MESH chain through the command:

iptables -t nat -nvL | grep EDGE-MESH

However, we can see the EDGE-MESH chain on the ubuntu 18.04 system.

PS:
what kind iptables centos8 use: iptables v1.8.2 (nf_tables)
what kind iptables ubuntu18.04 use: iptables v1.6.1 (legacy)

What you expected to happen:

No matter which system the edgemesh-agent is running on, you can use the iptables command to see the EDGE-MESH chain on the host.

Anything else we need to know?:

I found that there are two types of iptables: iptables-legacy and iptables-nft. The iptables chain and rules cannot be shared between the two, so the chain and rules created with iptables(legacy) cannot be seen in iptables(nf_tables).
Kube-Proxy also had the same problem, and k8s officially gave a repair plan, you can refer to: kubernetes/kubernetes#82966

Environment:

  • EdgeMesh version: v1.7.1
  • Kubernetes version (use kubectl version): v1.18.2
  • KubeEdge version(e.g. cloudcore --version and edgecore --version): v1.7.1

When refreshing iptables, there is a risk of communication interruption between the two services that are communicating

What happened:
When refreshing iptables, there is a risk of communication interruption between the two services that are communicating.

// Start iptables proxy
func (proxier *Proxier) Start() {
	go func() {
		ticker := time.NewTicker(5 * time.Minute)
		for {
			select {
			case <-ticker.C:
				proxier.FlushRules()     // interruption risk is here 
				proxier.EnsureRules()
			case <-beehiveContext.Done():
				proxier.FlushRules()
				return
			}
		}
	}()
}

What you expected to happen:

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

Anything else we need to know?:

Environment:

  • EdgeMesh version:

  • Kubernetes version (use kubectl version):

  • KubeEdge version(e.g. cloudcore --version and edgecore --version):

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

handle l4 proxy err : lb: service emojivoto.emoji-svc has no instances

What happened:
I tried to deploy emojivoto to test edgemesh. First, I modified the emojivoto yaml file because edgemesh does not support grpc:

apiVersion: v1
kind: Service
metadata:
  name: emoji-svc
  namespace: emojivoto
spec:
  selector:
    app: emoji-svc
  ports:
  - name: grpc    ---->  change grpc to tcp-0
    port: 8080
    targetPort: 8080
  - name: prom    ---->  change prom to tcp-1
    port: 8801
    targetPort: 8801

(As same as voting-svc)

Then I try to access this emoji-svc but failed:

[root@k8s-node1 ~]# telnet 10.104.47.78 8801
Trying 10.104.47.78...
Connected to 10.104.47.78.
Escape character is '^]'.
^]
telnet> Connection closed.

Anything else we need to know?:
edgemesh-agent log:

......
I0907 08:48:04.272090       1 proxy.go:37] clusterIP: 10.104.47.78, servicePort: 8080
W0907 08:48:04.272147       1 util.go:21] DestinationRule "emojivoto.emoji-svc" not found, use default strategy [RoundRobin] from config file
I0907 08:48:04.272160       1 log.go:181] DEBUG: add [2] handlers for chain [tcp]
I0907 08:48:04.272191       1 log.go:181] ERROR: Lb err: [service emojivoto.emoji-svc has no instances]
E0907 08:48:04.272194       1 tcp.go:64] handle l4 proxy err : lb: service emojivoto.emoji-svc has no instances
......

I guess the problem is here(https://github.com/kubeedge/edgemesh/blob/main/agent/pkg/chassis/registry/registry.go):


	// gen MicroServiceInstances
	for _, subset := range eps.Subsets {
		if len(subset.Ports) > 0 && subset.Ports[0].Port == int32(targetPort) {
			for _, addr := range subset.Addresses {
				if addr.NodeName == nil {
					// Each backend(Address) must have a nodeName, so we do not support custom Endpoints now.
					// This means that external services cannot be used.
					continue
				}
				microServiceInstances = append(microServiceInstances, &registry.MicroServiceInstance{
					InstanceID:   fmt.Sprintf("%s.%s|%s.%d", namespace, name, addr.IP, targetPort),
					ServiceID:    fmt.Sprintf("%s#%s#%s", namespace, name, addr.IP),
					HostName:     "",
					EndpointsMap: map[string]string{proto: fmt.Sprintf("%s:%s:%d", *addr.NodeName, addr.IP, targetPort)},
				})
			}
		}
	}

	// no instances found
	if len(microServiceInstances) == 0 {
		return nil, fmt.Errorf("service %s.%s has no instances", namespace, name)
	}

targetPort is 8080 but subset.Ports[0].Port is 8801, so the loop is skipped.

Environment:

  • EdgeMesh version: 1.8.0

  • Kubernetes version (use kubectl version): 119

  • KubeEdge version(e.g. cloudcore --version and edgecore --version): 1.8.0

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

03-configmap.yaml and 04-deployment.yaml are missing

What happened:

I am following README.md to test HTTP Gateway, but 03-configmap.yaml and 04-deployment.yaml are not found.

What you expected to happen:

03-configmap.yaml and 04-deployment.yaml are in code base.

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

Follow README.md to deploy edgemesh-gateway

Anything else we need to know?:

Environment:

  • EdgeMesh version: master

1.7.1 metaServer doesn't work well

What happened:

What you expected to happen:

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

Anything else we need to know?:

Environment:

  • EdgeMesh version: release-1.7

  • Kubernetes version (use kubectl version): 1.18.20

  • KubeEdge version(e.g. cloudcore --version and edgecore --version): 1.7.1

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu): 4
    • OS (e.g. cat /etc/os-release): centos 7.6
    • Kernel (e.g. uname -a): 5.13
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version): 1.7.1
    • Hardware configuration (e.g. lscpu): 4
    • OS (e.g. cat /etc/os-release): centos7.6
    • Kernel (e.g. uname -a): 5.13
    • Go version (e.g. go version):
    • Others:

####config

  edgeMesh:
    enable: false
 metaManager:
    contextSendGroup: hub
    contextSendModule: websocket
    enable: true
    metaServer:
      debug: true
      enable: true
    podStatusSyncInterval: 60
    remoteQueryTimeout: 60

api service success

exec  in edgecore node --    icurl 127.0.0.1:10550/api/v1/services --->   response success

curl service failed

[root@edge46 ~]# curl hostname-svc46.edgemesh-test:12345
curl: (6) Could not resolve host: hostname-svc46.edgemesh-test; Unknown error

kubectl check

[root@chenwei78 ~]# kubectl -n edgemesh-test get ep -owide
NAME             ENDPOINTS         AGE
hostname-svc     172.17.0.2:9376   24h
hostname-svc46   172.17.0.2:9376   34h
You have new mail in /var/spool/mail/root
[root@chenwei78 ~]# kubectl -n edgemesh-test get pod -owide
NAME              READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
hostname-edge     1/1     Running   0          25h   172.17.0.2   edge47   <none>           <none>
hostname-edge46   1/1     Running   0          25h   172.17.0.2   edge46   <none>           <none>
[root@chenwei78 ~]# kubectl -n edgemesh-test get svc -owide
NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)     AGE   SELECTOR
hostname-svc     ClusterIP   None         <none>        12345/TCP   24h   app=hostname-edge
hostname-svc46   ClusterIP   None         <none>        12345/TCP   34h   app=hostname-edge46

Typo in README

What happened:
In README.md

offen supposed to be often.
What you expected to happen:
No typo.

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

Anything else we need to know?:

Environment:

  • EdgeMesh version:

  • Kubernetes version (use kubectl version):

  • KubeEdge version(e.g. cloudcore --version and edgecore --version):

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

When deploy service, the service cannot be accessed until serveral minutes.

What happened:
When I deploy a ClusterIP service that is not proxied by edgemesh, the service is not available until serveral minutes.

What you expected to happen:
The service is available just when I deploy a new service that is not proxied by edgemesh.

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

  1. install edgemesh normally
  2. deploy a ClusterIP service labeled "noproxy=edgemesh"
  3. the service is not available。
    4)wait for a few minutes, the service is available.

Anything else we need to know?:

Environment:

  • EdgeMesh version:

  • Kubernetes version (use kubectl version):
    Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", GitCommit:"ca643a4d1f7bfe34773c74f79527be4afd95bf39", GitTreeState:"clean", BuildDate:"2021-07-15T21:04:39Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
    Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", GitCommit:"ca643a4d1f7bfe34773c74f79527be4afd95bf39", GitTreeState:"clean", BuildDate:"2021-07-15T20:59:07Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}

  • KubeEdge version(e.g. cloudcore --version and edgecore --version):

  • Cloud nodes Environment:

KubeEdge v1.8.1
- Hardware configuration (e.g. lscpu):
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 96
On-line CPU(s) list: 0-95
Thread(s) per core: 2
Core(s) per socket: 24
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz
Stepping: 7
CPU MHz: 1000.021
CPU max MHz: 2101.0000
CPU min MHz: 1000.0000
BogoMIPS: 4200.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 1024K
L3 cache: 36608K
NUMA node0 CPU(s): 0-23,48-71
NUMA node1 CPU(s): 24-47,72-95
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke avx512_vnni md_clear flush_l1d arch_capabilities
- OS (e.g. cat /etc/os-release):
NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

- Kernel (e.g. `uname -a`):

Linux a800-03 4.15.0-154-generic #161-Ubuntu SMP Fri Jul 30 13:04:17 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
- Go version (e.g. go version):
- Others:

-
Edge nodes Environment:
- edgecore version (e.g. `edgecore --version`):
- Hardware configuration (e.g. `lscpu`):
- OS (e.g. `cat /etc/os-release`):
- Kernel (e.g. `uname -a`):
- Go version (e.g. `go version`):
- Others:

After add a new edge node, the edge node can't access the service

I have two edge node, one node to curl service is normal, But after I add another edge node it can't access service:

 #curl -v -X GET 'http://nginx.default'
* Could not resolve host: nginx.default; 未知的错误
* Closing connection 0
curl: (6) Could not resolve host: nginx.default; 未知的错误
#curl 127.0.0.1:10550/api/v1/services
{"apiVersion":"v1","items":[],"kind":"ServiceList","metadata":{"selfLink":"/api/v1/services"}}

After I restart cloudcore and edgecore, It is ok.

Environment:

  • EdgeMesh version: v1.7.0
  • Kubernetes version (use kubectl version): v1.16.1
  • KubeEdge version(e.g. cloudcore --version and edgecore --version): v1.7.0

ERROR: Lb err: [pod list is empty] when accessing a service hosted on a different edge node

OS: ubuntu 20.04.4 LTS
KubeEdge version: v1.7.1
EdgeMesh version: v1.7.0
K8S version:1.9.0

I have an infrastructure composed of two edge nodes as shown in the picture below:

image

All nodes are healthy:

frapedge00001    Ready    agent,edge   53d   v1.19.3-kubeedge-v1.7.1
fraporion00001   Ready    master       53d   v1.19.12
fraprigel00001   Ready    agent,edge   47d   v1.19.3-kubeedge-v1.7.1

For both services, I can resolve the IP using dig from both VMs. This means that the edgemesh gateways are doing their job properly and can resolve the DNS query.

dig pedestrian-tracking-l2-edge-svc.default
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.16.1-Ubuntu <<>> pedestrian-tracking-l2-edge-svc.default
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58818
;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;pedestrian-tracking-l2-edge-svc.default. IN A

;; ANSWER SECTION:
pedestrian-tracking-l2-edge-svc.default. 64 IN A 10.96.42.43

;; Query time: 0 msec
;; SERVER: 172.17.0.1#53(172.17.0.1)
;; WHEN: Tue Aug 17 22:20:46 CST 2021
;; MSG SIZE  rcvd: 73
dig pedestrian-tracking-l1-edge-svc.default
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.16.1-Ubuntu <<>> pedestrian-tracking-l1-edge-svc.default
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30930
;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;pedestrian-tracking-l1-edge-svc.default. IN A

;; ANSWER SECTION:
pedestrian-tracking-l1-edge-svc.default. 64 IN A 10.107.107.57

;; Query time: 0 msec
;; SERVER: 172.17.0.1#53(172.17.0.1)
;; WHEN: Tue Aug 17 22:21:16 CST 2021
;; MSG SIZE  rcvd: 73

The problem arises when I try to reach the applications hosted on the respective pods by using simple curl calls. For example:

  • If I use curl from VM2 -> Service L2 or from VM1 -> Service L1, the call is successful because I can see from the logs of the pods that they receive a request (please ignore the method not allowed error, it's irrelevant). For example:
 curl --noproxy "*" http://pedestrian-tracking-l2-edge-svc.default:6000/sedna/feature_extraction -vvv
*   Trying 10.96.42.43:6000...
* TCP_NODELAY set
* Connected to pedestrian-tracking-l2-edge-svc.default (10.96.42.43) port 6000 (#0)
> GET /sedna/feature_extraction HTTP/1.1
> Host: pedestrian-tracking-l2-edge-svc.default:6000
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 405 Method Not Allowed
< Content-Length: 31
< Content-Type: application/json
< Date: Tue, 17 Aug 2021 12:47:59 GMT
< Server: uvicorn
<
* Connection #0 to host pedestrian-tracking-l2-edge-svc.default left intact
INFO:     7.182.8.34:57472 - "GET /sedna/feature_extraction HTTP/1.1" 405 Method Not Allowed
  • If I use curl from VM2 -> Service L1 or from VM1 -> Service L2, it doesn't work and the pod doesn't receive any request. Also, I can see the following error message in the edgemesh gateway:
I0817 12:48:35.426515       1 dns.go:298] [EdgeMesh] dns server parse pedestrian-tracking-l2-edge-svc.default ip 10.96.42.43
I0817 12:48:35.426860       1 serviceproxy.go:53] ip: 10.96.42.43 port: 6000
W0817 12:48:35.426996       1 strategy.go:21] failed to find default.pedestrian-tracking-l2-edge-svc DestinationRule, use default strategy RoundRobin from config file
I0817 12:48:35.427049       1 log.go:181] DEBUG: add [2] handlers for chain [http]
I0817 12:48:35.427227       1 log.go:181] ERROR: Lb err: [pod list is empty]
W0817 12:48:35.427481       1 http.go:61] read http request EOF

As you can see, it seems like no pods are associated with the service but this is not true as it works when the curl call it's executed from the same host hosting the service (not cross-VM).

support http protocol in cross lan communication

What would you like to be added/modified:
In the feature of session persistent and virtualService, the http data should be understand by edgemesh-agent, not transport by tcp transparently
Why is this needed:
session persistent and virtualService is the key feature of edgemesh, so it can not be abort after the feature of cross lan communication

'VirtualService' is deleted while 'Gateway' exists , EdgeMesh-Ingress-Gateway still works

What happened:

  1. 'Gateway' and 'VirtualService' all exist, EdgeMesh-Ingress-Gateway work ,it's ok
    image

2)only 'Gateway' exists,EdgeMesh-Ingress-Gateway fails,it shouldn't be
image

3)only 'VirtualService' exists, EdgeMesh-Ingress-Gateway works,it shouldn't be
image

What you expected to happen:
when 'Gateway' is deleted while 'VirtualService' still exists, EdgeMesh-Ingress-Gateway shoulen't work.

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

Anything else we need to know?:

Environment:

  • EdgeMesh version:

  • Kubernetes version (use kubectl version):

  • KubeEdge version(e.g. cloudcore --version and edgecore --version):

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

Failed to watch xxx: failed to list xxx net/http: TLS handshake timeout

What happened:

When I deployed edgemesh-agent-cloud, I found that it did not work properly. And when I execute docker logs -f <edgemesh_container_id>:

I0824 12:14:27.885528       1 trace.go:205] Trace[1396859110]: "Reflector ListAndWatch" name:/code/common/informers/informers.go:87 (24-Aug-2021 12:14:17.883) (total time: 10001ms):
Trace[1396859110]: [10.001600982s] [10.001600982s] END
E0824 12:14:27.885553       1 reflector.go:127] /code/common/informers/informers.go:87: Failed to watch *v1.Service: failed to list *v1.Service: Get "https://10.96.0.1:443/api/v1/services?limit=500&resourceVersion=0": net/http: TLS handshake timeout
I0824 12:14:27.885771       1 trace.go:205] Trace[1046529680]: "Reflector ListAndWatch" name:/code/common/informers/informers.go:87 (24-Aug-2021 12:14:17.883) (total time: 10002ms):
Trace[1046529680]: [10.002072265s] [10.002072265s] END
E0824 12:14:27.885780       1 reflector.go:127] /code/common/informers/informers.go:87: Failed to watch *v1alpha3.DestinationRule: failed to list *v1alpha3.DestinationRule: Get "https://10.96.0.1:443/apis/networking.istio.io/v1alpha3/destinationrules?limit=500&resourceVersion=0": net/http: TLS handshake timeout

The log of edgemesh-agent-cloud will print a lot of net/http: TLS handshake timeout.

Why?

This may be due to the residual iptables or ip route rules.

  1. Iptables rules remain like:
// in edgemesh-agent-cloud container
/ # iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 83 packets, 3968 bytes)
 pkts bytes target     prot opt in     out     source               destination
   83  3968 EDGE-MESH  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* edgemesh root chain */
    0     0 EDGE-MESH  tcp  --  *      *       0.0.0.0/0            10.96.0.0/12

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 5 packets, 342 bytes)
 pkts bytes target     prot opt in     out     source               destination
   50  3042 EDGE-MESH  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* edgemesh root chain */
   81  4860 EDGE-MESH  tcp  --  *      *       0.0.0.0/0            10.96.0.0/12

Chain POSTROUTING (policy ACCEPT 50 packets, 3042 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain EDGE-MESH (4 references)
 pkts bytes target     prot opt in     out     source               destination
   45  2700 EDGE-MESH-TCP  tcp  --  *      *       0.0.0.0/0            10.96.0.0/12         /* tcp service proxy */

Chain EDGE-MESH-TCP (1 references)
 pkts bytes target     prot opt in     out     source               destination
   45  2700 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            to:10.244.1.1:40001

PREROUTING chain and OUTPUT chain will have two EDGE-MESH targets. Then we need to delete the second rule later, for example:
Note: 2 is my iptables rule index, which may not be on your host!!!

iptables -t NAT -D PREROUTING 2
iptables -t NAT -D OUTPUT 2
  1. IP ruote table rules remain like:
[root@k8s-node1 ~]# ip route show
default via 192.168.0.1 dev eth0 proto dhcp metric 100
10.96.0.0/12 via 10.244.1.1 dev cni0
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink
10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1
169.254.169.254 via 192.168.0.254 dev eth0 proto dhcp metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.71 metric 100

The second route rule 10.96.0.0/12 via 10.244.0.1 dev cni0 is residual. Generally speaking, route rule will be cleared automatically when edgemesh-agent is shut down. If not, you need to clear it manually, for example:

ip route del 10.96.0.0/12 via 10.244.1.1 dev cni0

Finally, redeploy edgemesh-agent.

EdgeMesh-Gateway exit due to port conflict

What happened:
I create a gateway listening on port 12345, and on this machine, this port already on use
Then the process gateway exit due to the port conflict
What you expected to happen:
even the port conflict, the gateway log should print error but not exit
How to reproduce it (as minimally and precisely as possible):
create a app listen on 12345
create a gateway crd listen on 12345 too
Anything else we need to know?:

Environment:

  • EdgeMesh version:
    master branch

  • Kubernetes version (use kubectl version):
    1.20

  • KubeEdge version(e.g. cloudcore --version and edgecore --version):
    1.7.0

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

Test edgemesh on two nodes failed

OS: ubuntu 18.04.4 LTS
KubeEdge version: v1.7.1
EdgeMesh version: main branch
K8S version:1.9.0

Problem: curl service URL on both edge node are failed.

I have three nodes, one as a cloud node and two as edge nodes:
Cloud node: i-cpc3wtjy
Edge nodes: enode1, enode2

Install:
curl 127.0.0.1:10550/api/v1/services on both edge node are OK
Deploy edgemesh-server is done, public IP is set to node public IP 10.130.35.13.
Deploy edgemesh-agent is done, subNet is set.

cloud node:

root@i-cpc3wtjy:~# kubectl get svc
NAME                               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)     AGE
kubernetes                         ClusterIP   10.96.0.1       <none>        443/TCP     220d
pedestrian-search-reidworker-svc   ClusterIP   10.109.132.38   <none>        12345/TCP   97m
pedestrian-search-userworker-svc   ClusterIP   10.104.169.82   <none>        23456/TCP   97m

All nodes are healthy:

kubectl get pods -n kubeedge -o wide
NAME                               READY   STATUS    RESTARTS   AGE     IP             NODE
edgemesh-agent-4cmvw               1/1     Running   0          7m13s   192.168.0.12   enode1
edgemesh-agent-x5pr9               1/1     Running   0          7m13s   172.17.0.13    enode2
edgemesh-server-564469d5d7-b2v6w   1/1     Running   0          34m     10.130.35.13   i-cpc3wtjy  

enode1:

curl pedestrian-search-reidworker-svc:12345 -v

root@hecs-x-medium-2-linux-20200630092216:~# curl pedestrian-search-reidworker-svc:12345 -v
* Rebuilt URL to: pedestrian-search-reidworker-svc:12345/
*   Trying 10.109.132.38...
* TCP_NODELAY set
* connect to 10.109.132.38 port 12345 failed: Connection timed out
* Failed to connect to pedestrian-search-reidworker-svc port 12345: Connection timed out
* Closing connection 0
curl: (7) Failed to connect to pedestrian-search-reidworker-svc port 12345: Connection timed out

docker logs -f "edgemesh-agent conrainer id"

I0821 03:00:08.977538       1 core.go:24] Starting module edgedns
I0821 03:00:08.977936       1 core.go:24] Starting module edgeproxy
I0821 03:00:08.978415       1 core.go:24] Starting module tunnelagent
W0821 03:00:09.064619       1 tunnel.go:28] Connection between agent and server [/ip4/10.130.35.13/tcp/10004 /ip4/127.0.0.1/tcp/10004 /ip4/139.198.190.221/tcp/10004] is not established, try connect
I0821 03:00:09.064781       1 tunnel.go:31] Tunnel agent connecting to tunnel server
W0821 03:00:09.101015       1 tunnel.go:42] Set peer addr info to secret err: Update secret &Secret{ObjectMeta:{      0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] []  []},Data:map[string][]byte{},Type:,StringData:map[string]string{},Immutable:nil,} err: the body of the request was in an unknown format - accepted media types include: application/json, application/yaml
I0821 03:00:11.101244       1 tunnel.go:31] Tunnel agent connecting to tunnel server
W0821 03:00:11.102121       1 tunnel.go:42] Set peer addr info to secret err: Update secret &Secret{ObjectMeta:{      0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] []  []},Data:map[string][]byte{},Type:,StringData:map[string]string{},Immutable:nil,} err: the body of the request was in an unknown format - accepted media types include: application/json, application/yaml
I0821 03:00:13.102233       1 tunnel.go:31] Tunnel agent connecting to tunnel server
I0821 03:00:13.102371       1 tunnel.go:47] agent success connected to server [/ip4/10.130.35.13/tcp/10004 /ip4/127.0.0.1/tcp/10004 /ip4/139.198.190.221/tcp/10004]

E0821 04:40:48.114970       1 dns.go:112] service reverse clusterIP error: service "pedestrian-search-reidworker-svc" not found
W0821 04:40:48.114991       1 dns.go:57] resolve dns: get from real dns
W0821 04:40:48.116584       1 dns.go:57] resolve dns: get from real dns
I0821 04:40:48.117760       1 dns.go:115] dns server parse pedestrian-search-reidworker-svc ip 10.109.132.38

enode2:

curl pedestrian-search-reidworker-svc:12345 -v

root@VM-0-13-ubuntu:/home/ubuntu# curl pedestrian-search-reidworker-svc:12345 -v
* Rebuilt URL to: pedestrian-search-reidworker-svc:12345/
* Could not resolve host: pedestrian-search-reidworker-svc
* Closing connection 0
curl: (6) Could not resolve host: pedestrian-search-reidworker-svc

docker logs -f "edgemesh-agent conrainer id"

W0821 02:59:56.638070       1 tunnel.go:28] Connection between agent and server [/ip4/10.130.35.13/tcp/10004 /ip4/127.0.0.1/tcp/10004 /ip4/139.198.190.221/tcp/10004] is not established, try connect
I0821 02:59:56.638172       1 tunnel.go:31] Tunnel agent connecting to tunnel server
W0821 02:59:56.833292       1 tunnel.go:42] Set peer addr info to secret err: Update secret &Secret{ObjectMeta:{      0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] []  []},Data:map[string][]byte{},Type:,StringData:map[string]string{},Immutable:nil,} err: the body of the request was in an unknown format - accepted media types include: application/json, application/yaml
I0821 02:59:58.833519       1 tunnel.go:31] Tunnel agent connecting to tunnel server
W0821 02:59:58.834299       1 tunnel.go:42] Set peer addr info to secret err: Update secret &Secret{ObjectMeta:{      0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] []  []},Data:map[string][]byte{},Type:,StringData:map[string]string{},Immutable:nil,} err: the body of the request was in an unknown format - accepted media types include: application/json, application/yaml
I0821 03:00:00.834388       1 tunnel.go:31] Tunnel agent connecting to tunnel server
I0821 03:00:00.834501       1 tunnel.go:47] agent success connected to server [/ip4/10.130.35.13/tcp/10004 /ip4/127.0.0.1/tcp/10004 /ip4/139.198.190.221/tcp/10004]
W0821 03:00:04.624165       1 dns.go:57] resolve dns: get from real dns
W0821 03:00:04.624834       1 dns.go:57] resolve dns: get from real dns
W0821 03:00:04.627217       1 dns.go:57] resolve dns: get from real dns
W0821 03:00:04.627695       1 dns.go:57] resolve dns: get from real dns

The service port name restriction should be removed

What would you like to be added/modified:
In current edgemesh version , the service port name has the following restriction: "Service ports must be named. The key/value pairs of port name must have the following syntax: name: [-]"

The restriction should be removed.

Why is this needed:
This problem is easily triggered. As a result, services cannot be accessed accross cloud and edge.

Case "HTTPS GateWay": use "curl -k" is enough without key file

What happened:
Using “curl -k https://ip:port” without certificate file is enough to access the service.
image

What you expected to happen:
When gateway is mode " https", accessing the service must carrying certificate files

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

Anything else we need to know?:
Test procedure:
1)create a test key file:
image
2)create a 'Secret' according to the key file:
image
image
3)create 'Gateway' and 'VirtualService'
cat gateway.yaml:
image

Environment:

  • EdgeMesh version: release-1.7

  • Kubernetes version (use kubectl version): Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.4", GitCommit:"d360454c9bcd1634cf4cc52d1867af5491dc9c5f", GitTreeState:"clean", BuildDate:"2020-11-11T13:17:17Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
    Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:48:36Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

  • KubeEdge version(e.g. cloudcore --version and edgecore --version): cloudcore: release-1.7, edgecore: release-1.7

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

Secret cannot be updated when edgemesh-agent is started

What happened:
I used the list-watch capability provided by edgecore. And when I try to update the secret, I receive an error log:

W0819 02:46:03.954397       1 tunnel.go:42] Set peer addr info to secret err: Update secret &Secret{ObjectMeta:{      0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] []  []},Data:map[string][]byte{},Type:,StringData:map[string]string{},Immutable:nil,} err: the body of the request was in an unknown format - accepted media types include: application/json, application/yaml

Anything else we need to know?:
This problem has been solved, you can refer to kubeedge/kubeedge#3041

Environment:

Problems with accessing external services through edgemesh at the edge

What happened:

Prerequisites

make a ubuntu-test image from ubuntu:21.04, and install with telnet, net-tools, dnsutils, mosquitto, mosquitto-clients, inetutils-ping etc.

run it to a container from yaml:

apiVersion: v1
kind: Pod
metadata:
  name: edge-ubuntu-test
spec:
  nodeSelector:
    node-role.kubernetes.io/edge: ""
  containers:
  - name: edge-ubuntu-test
    image: ubuntu-test:21.04
    # Just spin & wait forever
    command: [ "/bin/bash", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]

Success case

在边缘端pod层面创建一个mosquitto容器,供边缘端edge-ubuntu-test访问。
Create a mosquitto container at the edge pod for access by edge-ubuntu-test.

service -> endpoints

  1. configmap-mosquitto.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: mosquitto-config
  labels:
    app: chirpstack-mosquitto  
data:
  mosquitto.conf: |    
    persistence true
    persistence_location /mosquitto/data/
    # per_listener_settings false
    log_dest stdout
    # listener 1886
    listener 31883 0.0.0.0
    protocol mqtt
    
    listener 32901 0.0.0.0
    protocol websockets
    # Defaults to false, unless there are no listeners defined in the configuration
    # file, in which case it is set to true, but connections are only allowed from
    # the local machine.
    allow_anonymous true
    #    password_file /.config/mosquitto/auth/password_file.txt
    #    cafile: /mosquitto/config/certs/ca.crt
    #    certfile: /mosquitto/config/certs/server.crt
    #    keyfile: /mosquitto/config/certs/server.key
    require_certificate false
    use_identity_as_username false
  1. deployment-chirpstack-mosquitto.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: chirpstack-mosquitto
spec:
  replicas: 1
  selector:
    matchLabels:
      app: chirpstack-mosquitto
  template:
    metadata:
      labels:
        app: chirpstack-mosquitto
    spec:
      nodeSelector:
        node-role.kubernetes.io/edge: ""
      containers:
      - name: chirpstack-mosquitto
        image: eclipse-mosquitto:2.0.10
        ports:
        - containerPort: 31883
          name: mqtt
          hostPort: 31883
        volumeMounts:
        - name: mosquitto-data
          mountPath: /mosquitto/data
        - name: mosquitto-log
          mountPath: /mosquitto/log
        - name: config-file
          mountPath: /mosquitto/config/mosquitto.conf
          subPath: mosquitto.conf         
      securityContext:
        runAsNonRoot: true
        fsGroup: 1
        runAsGroup: 1000
        runAsUser: 1000
        supplementalGroups:
        - 1    
      volumes:
      - name: config-file
        configMap:
          name: mosquitto-config
      - name: password-file
        configMap:
          name: mosquitto-password        
      - name: mosquitto-data
        emptyDir: {}
      - name: mosquitto-log
        emptyDir: {} 
  1. svc-mosquitto.yaml
apiVersion: v1
kind: Service
metadata:
  name: chirpstack-mosquitto
  labels:
    app: chirpstack-mosquitto
spec:
  type: ClusterIP
  ports:
    - name: tcp-mqtt 
      port: 31883
      targetPort: 31883
      protocol: TCP  
  selector:
    app: chirpstack-mosquitto

validate the dns

root@ubuntu:/# dig -t A chirpstack-mosquitto
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.16.8-Ubuntu <<>> -t A chirpstack-mosquitto
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61934
;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;chirpstack-mosquitto.		IN	A

;; ANSWER SECTION:
chirpstack-mosquitto.	64	IN	A	10.10.5.202

;; Query time: 0 msec
;; SERVER: 172.17.0.1#53(172.17.0.1)
;; WHEN: Thu Jun 10 13:45:27 CST 2021
;; MSG SIZE  rcvd: 54

pub and sub the broker of service -> endpoints

mosquitto_sub -h chirpstack-mosquitto -p 31883 -t test

sub-service-endpoints

mosquitto_pub -h chirpstack-mosquitto -p 31883 -t test -m 'hello'

pub-service-endpoints

edgemesh's log

I0610 05:27:48.565550       1 dns.go:298] [EdgeMesh] dns server parse chirpstack-mosquitto ip 10.10.5.202
W0610 05:27:48.565628       1 dns.go:136] [EdgeMesh] failed to resolve dns: get from real dns
I0610 05:27:48.571146       1 serviceproxy.go:53] ip: 10.10.5.202 port: 31883
I0610 05:27:48.571192       1 serviceproxy.go:125] newProtocolFromSock().svcPorts:tcp,31883,31883|http,32901,32901|default.chirpstack-mosquitto
W0610 05:27:48.571259       1 strategy.go:21] failed to find default.chirpstack-mosquitto DestinationRule, use default strategy RoundRobin from config file
I0610 05:27:48.571267       1 tcp.go:84] MicroServiceName:chirpstack-mosquitto.default.svc.cluster.local:31883, Endpoint:, Port:, SourceServiceID:, Protocol:tcp, Strategy:RoundRobin, Args:[]
I0610 05:27:48.571284       1 log.go:181] DEBUG: add [2] handlers for chain [tcp]
I0610 05:27:48.571440       1 tcp.go:120] responseCallback:ep:192.168.241.181:31883
I0610 05:27:48.571455       1 tcp.go:144] l4 proxy get server address: 192.168.241.181:31883
I0610 05:27:48.572029       1 tcp.go:187] l4 Proxy start a proxy to server 192.168.241.181:31883
I0610 05:27:48.623079       1 tcp.go:212] processClientProxy read err: EOF
I0610 05:27:48.623282       1 tcp.go:257] processServerProxy read err: EOF
E0610 05:27:48.623295       1 tcp.go:260] rconn close err: close tcp 192.168.241.180:49800->192.168.241.181:31883: use of closed network connection
E0610 05:27:48.623306       1 tcp.go:264] lconn close err: close tcp 172.17.0.1:40001->172.17.0.3:40780: use of closed network connection

Failed case

将宿主机的mosquitto当作外部资源引入到Service层,这种方式需要先创建Endpoints,然后创建同名的Service与之对应。
Mapping the host's mosquitto as an external resource to the Service layer. In this way, you need to create Endpoints first, and then create a Service with the same name to correspond to it.

endpoints -> service

  1. endpoint-edge1.yaml
kind: Endpoints
apiVersion: v1
metadata:
  name: mosquitto-host-edge1
  namespace: default
subsets:
  - addresses:
      - ip: 192.168.241.180
    ports:
      - port: 1883
        name: tcp-mqtt-edge1
  1. service-edge1.yaml
apiVersion: v1
kind: Service
metadata:
  name: mosquitto-host-edge1
spec:
  ports:
    - port: 1883
      name: tcp-mqtt-edge1
      protocol: TCP

validate the dns

root@ubuntu:/# dig -t A mosquitto-host-edge1
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.16.8-Ubuntu <<>> -t A mosquitto-host-edge1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58529
;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;mosquitto-host-edge1.		IN	A

;; ANSWER SECTION:
mosquitto-host-edge1.	64	IN	A	10.10.179.131

;; Query time: 0 msec
;; SERVER: 172.17.0.1#53(172.17.0.1)
;; WHEN: Thu Jun 10 13:30:08 CST 2021
;; MSG SIZE  rcvd: 54

sub the broker of endpoint -> service

mosquitto_sub -h mosquitto-host-edge1 -p 1883 -t test

NOTE! Start the mosquitto_sub process, the edgemesh continue to report errors.
edgemesh's log

I0610 05:31:43.840156       1 dns.go:298] [EdgeMesh] dns server parse mosquitto-host-edge1 ip 10.10.179.131
W0610 05:31:43.840216       1 dns.go:136] [EdgeMesh] failed to resolve dns: get from real dns
I0610 05:31:43.845059       1 serviceproxy.go:53] ip: 10.10.179.131 port: 1883
I0610 05:31:43.845071       1 serviceproxy.go:125] newProtocolFromSock().svcPorts:tcp,1883,1883|default.mosquitto-host-edge1
W0610 05:31:43.845138       1 strategy.go:21] failed to find default.mosquitto-host-edge1 DestinationRule, use default strategy RoundRobin from config file
I0610 05:31:43.845144       1 tcp.go:84] MicroServiceName:mosquitto-host-edge1.default.svc.cluster.local:1883, Endpoint:, Port:, SourceServiceID:, Protocol:tcp, Strategy:RoundRobin, Args:[]
I0610 05:31:43.845152       1 log.go:181] DEBUG: add [2] handlers for chain [tcp]
I0610 05:31:43.845184       1 tcp.go:120] responseCallback:ep:192.168.241.181:0
I0610 05:31:43.845188       1 tcp.go:144] l4 proxy get server address: 192.168.241.181:0
E0610 05:31:43.845766       1 tcp.go:156] l4 proxy dial server error: dial tcp 192.168.241.181:0: connect: connection refused
I0610 05:31:44.847295       1 dns.go:298] [EdgeMesh] dns server parse mosquitto-host-edge1 ip 10.10.179.131
W0610 05:31:44.847334       1 dns.go:136] [EdgeMesh] failed to resolve dns: get from real dns
I0610 05:31:44.852629       1 serviceproxy.go:53] ip: 10.10.179.131 port: 1883
I0610 05:31:44.852655       1 serviceproxy.go:125] newProtocolFromSock().svcPorts:tcp,1883,1883|default.mosquitto-host-edge1
W0610 05:31:44.852688       1 strategy.go:21] failed to find default.mosquitto-host-edge1 DestinationRule, use default strategy RoundRobin from config file
I0610 05:31:44.852693       1 tcp.go:84] MicroServiceName:mosquitto-host-edge1.default.svc.cluster.local:1883, Endpoint:, Port:, SourceServiceID:, Protocol:tcp, Strategy:RoundRobin, Args:[]
I0610 05:31:44.852718       1 log.go:181] DEBUG: add [2] handlers for chain [tcp]
I0610 05:31:44.852765       1 tcp.go:120] responseCallback:ep:192.168.241.181:0
I0610 05:31:44.852771       1 tcp.go:144] l4 proxy get server address: 192.168.241.181:0
E0610 05:31:44.853449       1 tcp.go:156] l4 proxy dial server error: dial tcp 192.168.241.181:0: connect: connection refused
......

pub the broker of endpoint -> service

  1. sub the topic from edge1 host
[root@ke-edge1 ~]# mosquitto_sub -h 127.0.0.1 -p 1883 -t test
  1. pub the topic from pod in the edge
root@ubuntu:/# mosquitto_pub -h mosquitto-host-edge1 -p 1883 -t test -m 'hello'
Error: The connection was lost.
  1. NOTE! Start the mosquitto_pub process, the edgemesh report error, and the mosquitto_sub 127.0.0.1 is no message is received.
    edgemesh's log
I0610 05:33:14.925329       1 dns.go:298] [EdgeMesh] dns server parse mosquitto-host-edge1 ip 10.10.179.131
W0610 05:33:14.925426       1 dns.go:136] [EdgeMesh] failed to resolve dns: get from real dns
I0610 05:33:14.930465       1 serviceproxy.go:53] ip: 10.10.179.131 port: 1883
I0610 05:33:14.930477       1 serviceproxy.go:125] newProtocolFromSock().svcPorts:tcp,1883,1883|default.mosquitto-host-edge1
W0610 05:33:14.930507       1 strategy.go:21] failed to find default.mosquitto-host-edge1 DestinationRule, use default strategy RoundRobin from config file
I0610 05:33:14.930511       1 tcp.go:84] MicroServiceName:mosquitto-host-edge1.default.svc.cluster.local:1883, Endpoint:, Port:, SourceServiceID:, Protocol:tcp, Strategy:RoundRobin, Args:[]
I0610 05:33:14.930519       1 log.go:181] DEBUG: add [2] handlers for chain [tcp]
I0610 05:33:14.930588       1 tcp.go:120] responseCallback:ep:192.168.241.170:0
I0610 05:33:14.930593       1 tcp.go:144] l4 proxy get server address: 192.168.241.170:0
E0610 05:33:14.931273       1 tcp.go:156] l4 proxy dial server error: dial tcp 192.168.241.170:0: connect: connection refused

I modified part of the log output, trying to find the cause of the error, but I suffered from the lack of knowledge of the principle;
What you expected to happen:
It is passable to run the second test case in the k8s cloud.

Environment:

  • EdgeMesh version: branch release-1.7

  • Kubernetes version (use kubectl version):
    Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.10", GitCommit:"98d5dc5d36d34a7ee13368a7893dcb400ec4e566", GitTreeState:"clean", BuildDate:"2021-04-15T03:28:42Z", GoVersion:"go1.15.10", Compiler:"gc", Platform:"linux/amd64"}
    Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.10", GitCommit:"98d5dc5d36d34a7ee13368a7893dcb400ec4e566", GitTreeState:"clean", BuildDate:"2021-04-15T03:20:25Z", GoVersion:"go1.15.10", Compiler:"gc", Platform:"linux/amd64"}

  • KubeEdge version(e.g. cloudcore --version and edgecore --version):
    branch release-1.7

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
      Architecture: x86_64
      CPU op-mode(s): 32-bit, 64-bit
      Byte Order: Little Endian
      CPU(s): 4
      On-line CPU(s) list: 0-3
      Thread(s) per core: 1
      Core(s) per socket: 2
      Socket(s): 2
      NUMA node(s): 1
      Vendor ID: GenuineIntel
      CPU family: 6
      Model: 142
      Model name: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz
      Stepping: 12
      CPU MHz: 2112.048
      BogoMIPS: 4224.00
      Hypervisor vendor: VMware
      Virtualization type: full
      L1d cache: 32K
      L1i cache: 32K
      L2 cache: 256K
      L3 cache: 6144K
      NUMA node0 CPU(s): 0-3
      Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 arat
    • OS (e.g. cat /etc/os-release):
      NAME="CentOS Linux"
      VERSION="7 (Core)"
      ID="centos"
      ID_LIKE="rhel fedora"
      VERSION_ID="7"
      PRETTY_NAME="CentOS Linux 7 (Core)"
      ANSI_COLOR="0;31"
      CPE_NAME="cpe:/o:centos:centos:7"
      HOME_URL="https://www.centos.org/"
      BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

- Kernel (e.g. `uname -a`):

Linux ke-master1 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
- Go version (e.g. go version):
go version go1.14.15 linux/amd64
- Others:

-
Edge nodes Environment: Same to cloud

Deploying edgemesh failed

What happened:

I deployed edgeMesh following the readme, but it doesn’t seem to work
I prepared two nodes, a master node and an edge node.
I run a Pod on the edge node, and the yaml files of the pod and service are as follows:

apiVersion: v1
kind: Pod
metadata:
name: pod-b
labels:
app: edge-nginx
spec:
containers:
- image: nginx
name: hello
ports:
- containerPort: 9376
hostPort: 9376
nodeSelector:
type: dao-48-21
tolerations:
- effect: PreferNoSchedule
key: node-role.kubernetes.io/master
operator: Exists
- effect: NoSchedule
key: node-role.kubernetes.io/master
operator: Exists
- effect: NoSchedule
key: dec.daocloud.io/edge
operator: Equal
value: dao-48-21

apiVersion: v1
kind: Service
metadata:
name: edge-nginx
namespace: default
spec:
ports:
- name: http-0
port: 18080
protocol: TCP
targetPort: 9376
selector:
app: edge-nginx
clusterIP: None

NAME                        READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
pod-b                       1/1     Running   0          39h   172.17.0.2    dao-48-21   <none>           <none>
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE    SELECTOR
edge-nginx   ClusterIP   None             <none>        18080/TCP        39h    app=edge-nginx
NAME         ENDPOINTS         AGE
edge-nginx   172.17.0.2:9376   39h

I successfully performed the following operations at the edge node:

nano@nano-desktop:~$ curl 172.17.0.2
<!DOCTYPE html>
<html>
···
</body>
</html>

But when I try to connect through the domain name, it fails:

nano@nano-desktop:~$ curl http://edge-nginx.default.svc.cluster.local:9376curl: (6) Could not resolve host: edge-nginx.default.svc.cluster.local  

What you expected to happen:
I want to get the Nginx response

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

Anything else we need to know?:

Environment:

  • EdgeMesh version:
  • Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0", GitCommit:"af46c47ce925f4c4ad5cc8d1fca46c7b77d13b38", GitTreeState:"clean", BuildDate:"2020-12-08T17:59:43Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0", GitCommit:"af46c47ce925f4c4ad5cc8d1fca46c7b77d13b38", GitTreeState:"clean", BuildDate:"2020-12-08T17:51:19Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}  
  • KubeEdge version(e.g. cloudcore --version and edgecore --version):

KubeEdge v1.6.0-beta.0.182+beed66d71625f5

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):

    edgecore --version: command not found

    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

安装edgemesh后,服务域名解析失败

What happened:
安装edgemesh后,在中心集群的节点上POD内无法解析域名(使用服务的Cluster-IP可正常访问服务)
What you expected to happen:
在中心集群的节点上POD内能正常解析域名
How to reproduce it (as minimally and precisely as possible):
正常安装edgemesh后,出现此现象
Anything else we need to know?:

Environment:

  • EdgeMesh version: kubeedge/edgemesh-agent:latest

  • Kubernetes version (use kubectl version): 1.21.3

  • KubeEdge version(e.g. cloudcore --version and edgecore --version): 1.7.2

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):

    • Architecture: x86_64
      CPU op-mode(s): 32-bit, 64-bit
      Byte Order: Little Endian
      CPU(s): 56
      On-line CPU(s) list: 0-55
      Thread(s) per core: 2
      Core(s) per socket: 14
      Socket(s): 2
      NUMA node(s): 2
      Vendor ID: GenuineIntel
      CPU family: 6
      Model: 85
      Model name: Intel(R) Xeon(R) Gold 6132 CPU @ 2.60GHz
      Stepping: 4
      CPU MHz: 3307.946
      BogoMIPS: 5200.00
      Virtualization: VT-x
      L1d cache: 32K
      L1i cache: 32K
      L2 cache: 1024K
      L3 cache: 19712K
      NUMA node0 CPU(s): 0-13,28-41
      NUMA node1 CPU(s): 14-27,42-55

    • OS (e.g. cat /etc/os-release):
      NAME="Ubuntu"
      VERSION="18.04.5 LTS (Bionic Beaver)"

    • Kernel (e.g. uname -a):
      Linux controller04 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

    • Go version (e.g. go version):
      go version go1.14.4 linux/amd64

    • Others:

  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
      KubeEdge v1.7.2

    • Hardware configuration (e.g. lscpu):
      Architecture: x86_64
      CPU op-mode(s): 32-bit, 64-bit
      Byte Order: Little Endian
      CPU(s): 64

    • OS (e.g. cat /etc/os-release):
      NAME="Ubuntu"
      VERSION="18.04.6 LTS (Bionic Beaver)"
      ID=ubuntu
      ID_LIKE=debian
      PRETTY_NAME="Ubuntu 18.04.6 LTS"
      VERSION_ID="18.04"

    • Kernel (e.g. uname -a):
      Linux infer-1 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

    • Go version (e.g. go version):

    • Others:

edgemesh-agent-cloud work unnormally in cloud node

What happened:
I have three nodes, one for cloud node called ke-cloud, two for edge nodes called ke-edge1 and ke-edge2. I have deployed edgemesh-agent-cloud and scheduled to ke-cloud successfully, but it's status is CrashLoopBackOff. The container logs shows that
F0914 06:11:11.697742 1 server.go:56] run edgemesh-agent failed: [
register module edgeproxy error: get proxy listen ip err: route ip+net: no such network interface
]

What you expected to happen:
edgemesh-agent-cloud work normally
How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

  • EdgeMesh version: v1.8.0

  • Kubernetes version (use kubectl version):Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:20:10Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}
    Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.17", GitCommit:"f3abc15296f3a3f54e4ee42e830c61047b13895f", GitTreeState:"clean", BuildDate:"2021-01-13T13:13:00Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

  • KubeEdge version(e.g. cloudcore --version and edgecore --version): v1.8.0

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release): CentOS 7.9
    • Kernel (e.g. uname -a): Linux ke-cloud 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

The default ports of edgemesh-server and edgeStream conflict

The The default ports of edgemesh-server and edgeStream conflict.

Environment:

  • EdgeMesh version:1.8.0
  • Kubernetes version (use kubectl version):1.20.4
  • KubeEdge version(e.g. cloudcore --version and edgecore --version):1.6.2
edgemesh-server.yaml  

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: kubeedge
    kubeedge: edgemesh-server
  name: edgemesh-server
  namespace: kubeedge
spec:
  selector:
    matchLabels:
      k8s-app: kubeedge
      kubeedge: edgemesh-server
  template:
    metadata:
      labels:
        k8s-app: kubeedge
        kubeedge: edgemesh-server
    spec:
      hostNetwork: true
#     use label to selector node
      nodeName: marsone-cloud
      containers:
      - name: edgemesh-server
        image: kubeedge/edgemesh-server:latest
        env:
          - name: MY_NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
        ports:
        - containerPort: 10004
---
cloudcore 

apiVersion: cloudcore.config.kubeedge.io/v1alpha2
    kind: CloudCore
    kubeAPIConfig:
      kubeConfig: ""
      master: ""
    modules:
      cloudHub:
        advertiseAddress:
        - 159.75.202.72
        nodeLimit: 100
        tlsCAFile: /etc/kubeedge/ca/rootCA.crt
        tlsCertFile: /etc/kubeedge/certs/edge.crt
        tlsPrivateKeyFile: /etc/kubeedge/certs/edge.key
        unixsocket:
          address: unix:///var/lib/kubeedge/kubeedge.sock
          enable: true
        websocket:
          address: 0.0.0.0
          enable: true
          port: 10000
        quic:
          address: 0.0.0.0
          enable: false
          maxIncomingStreams: 10000
          port: 10001
        https:
          address: 0.0.0.0
          enable: true
          port: 10002
      cloudStream:
        enable: true
        streamPort: 10003
        tunnelPort: 10004
      dynamicController:
        enable: true

Hardcoded edgemesh-server port

What happened:
Changing the port of the edgemesh-server in the YAML file does not affect the port on which the pod will listen to. It will always listen on port 10004 because it's hardcoded -> check here.

What you expected to happen:
Changing the port in the YAML file should affect the port on which edgemesh-server is deployed.

How to reproduce it (as minimally and precisely as possible):
Change the port in the deployment YAML file.

Just test

What happened:

What you expected to happen:

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

Anything else we need to know?:

Environment:

  • EdgeMesh version:

  • Kubernetes version (use kubectl version):

  • KubeEdge version(e.g. cloudcore --version and edgecore --version):

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

Session Persistence can't use when transport http data through tcp

What happened:
Session Persistence can not work after transport http data through tcp
What you expected to happen:
Session Persistence can work well
How to reproduce it (as minimally and precisely as possible):
create a deployment contains three http server
create a service associate with this three pods
create a destination rule associate with this service and the load balance policy set as consistent hash
Anything else we need to know?:

Environment:

  • EdgeMesh version:

  • Kubernetes version (use kubectl version):

  • 1.20.0

  • KubeEdge version(e.g. cloudcore --version and edgecore --version):

  • 1.7.1

  • Cloud nodes Environment:
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:
  • Edge nodes Environment:
    • edgecore version (e.g. edgecore --version):
    • Hardware configuration (e.g. lscpu):
    • OS (e.g. cat /etc/os-release):
    • Kernel (e.g. uname -a):
    • Go version (e.g. go version):
    • Others:

Security for EdgeMesh

What would you like to be added/modified:
Add security for EdgeMesh

Why is this needed:
EdgeMesh's services form a communication network to provide data communication functions for other services. The system may be invaded by other services, or communication data may be intercepted and cracked.

Make the expression unified

What would you like to be added/modified:

Make the expression unified.
image

Why is this needed:
A unified expression makes user more comfortable.

Wrong Service Name in Usecase HTTP

In HTTP Usecase, README asks me to use "hostname-lb-svc" to call the service, but actually the service in examples/hostname.yaml has a name of "hostname-svc".
image
image

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.