Merge pull request #1508 from spidernet-io/main

Merge main

.github/workflows/e2e-init.yaml

@@ -154,8 +154,7 @@ jobs:
 
       - name: Get the E2E Performance Result For Dual-stack
         id: get_performance
-        # TODO(ty-dc),Pending
-        if: ${{ inputs.ip_family == 'Pending' }}
+        if: ${{ inputs.ip_family == 'dual' }}
         shell: bash
         run: |
           # sudo apt-get install -y jq
@@ -165,7 +164,7 @@ jobs:
           echo ::set-output name=result::${TODO_STATUS}
 
       - name: Update Badge For Dual-stack
-        if: ${{ steps.get_performance.outputs.result != '' && inputs.ip_family == 'Pending' }}
+        if: ${{ steps.get_performance.outputs.result != '' && inputs.ip_family == 'dual' }}
         uses: schneegans/[email protected]
         with:
           auth: ${{ secrets.WELAN_PAT }}

.trivyignore

@@ -0,0 +1,2 @@
+# Skip checking whether role permits specific verb on wildcard resources.
+AVD-KSV-0046

CODEOWNERS

@@ -26,3 +26,4 @@
 /codecov.yml @weizhoublue
 /.golangci.yaml @weizhoublue
 /MAINTAINERS.md @weizhoublue
+/.trivyignore @weizhoublue

Makefile

@@ -386,7 +386,8 @@ lint_image_trivy: IMAGE_NAME ?=
 lint_image_trivy:
 	@ [ -n "$(IMAGE_NAME)" ] || { echo "error, please input IMAGE_NAME" && exit 1 ; }
 	@ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
- 		  -v /tmp/trivy:/root/trivy.cache/  \
+          -v $(ROOT_DIR)/.trivyignore:/.trivyignore \
+          -v /tmp/trivy:/root/trivy.cache/  \
           aquasec/trivy:latest image --exit-code 1  --severity $(LINT_TRIVY_SEVERITY_LEVEL)  $(IMAGE_NAME) ; \
       (($$?==0)) || { echo "error, failed to check dockerfile trivy", $(IMAGE_NAME)  && exit 1 ; } ; \
       echo "trivy check: $(IMAGE_NAME) pass"
@@ -395,7 +396,8 @@ lint_image_trivy:
 .PHONY: lint_dockerfile_trivy
 lint_dockerfile_trivy:
 	@ docker run --rm \
- 		  -v /tmp/trivy:/root/trivy.cache/  \
+          -v $(ROOT_DIR)/.trivyignore:/.trivyignore \
+          -v /tmp/trivy:/root/trivy.cache/  \
           -v $(ROOT_DIR):/tmp/src  \
           aquasec/trivy:latest config --exit-code 1  --severity $(LINT_TRIVY_SEVERITY_LEVEL) /tmp/src/images  ; \
       (($$?==0)) || { echo "error, failed to check dockerfile trivy" && exit 1 ; } ; \
@@ -405,9 +407,9 @@ lint_dockerfile_trivy:
 .PHONY: lint_chart_trivy
 lint_chart_trivy:
 	@ docker run --rm \
- 		  -v /tmp/trivy:/root/trivy.cache/  \
+          -v $(ROOT_DIR)/.trivyignore:/.trivyignore \
+          -v /tmp/trivy:/root/trivy.cache/  \
           -v $(ROOT_DIR):/tmp/src  \
           aquasec/trivy:latest config --exit-code 1  --severity $(LINT_TRIVY_SEVERITY_LEVEL) /tmp/src/charts  ; \
       (($$?==0)) || { echo "error, failed to check chart trivy" && exit 1 ; } ; \
       echo "chart trivy check: pass"
-

README.md

@@ -32,7 +32,7 @@ Despite no strict definition for underlay and overlay networks in cloud-native n
 
 ### Overlay network solution
 
-Theses solutions implements the decoupling of POD network and host network, such as [Calico](https://github.com/projectcalico/calico), [Cilium](https://github.com/cilium/cilium) and other CNI plugins. They either use tunneling technologies such as vxlan to build an overlay network plane, and then employ NAT for north-south traffic, or they use BGP routing protocols to open up the routes of the host network so that the host network can forward the POD's East-west and north-south traffic.
+These solutions implement the decoupling of POD network and host network, such as [Calico](https://github.com/projectcalico/calico), [Cilium](https://github.com/cilium/cilium) and other CNI plugins. They either use tunneling technologies such as vxlan to build an overlay network plane, and then employ NAT for north-south traffic, or they use BGP routing protocols to open up the routes of the host network so that the host network can forward the POD's East-west and north-south traffic.
 
 The characteristics of these IPAM solutions for overlay networks:
 
@@ -46,11 +46,11 @@ The characteristics of these IPAM solutions for overlay networks:
 
 2. Sufficient IP address resources
 
-    As we all know, IPv6 address resources are abundant while IPv4 addresses are scarce. Because POD subnets can be planned independently under the "overlay network solution", a kubernetes cluster can have enough IP address resources as long as NAT technology is used in a appropriate manner. As a result, applications do not fail to start due to insufficient IPs, and IPAM components face less pressure to recover abnormal IPs.
+    As we all know, IPv6 address resources are abundant while IPv4 addresses are scarce. Because POD subnets can be planned independently under the "overlay network solution", a kubernetes cluster can have enough IP address resources as long as NAT technology is used in an appropriate manner. As a result, applications do not fail to start due to insufficient IPs, and IPAM components face less pressure to recover abnormal IPs.
 
 3. No requirement for static application IP addresses
 
-    For the static IP address requirement, there is a difference between stateless application and stateful application. Regarding stateless application like deployment, the POD's name will change when the POD restart. Moreover, the business logic of the application itself is stateless, so static IP addresses are enabled only if all the POD replicas are fixed in a set of IP addresses; for stateful applications such as statefulset, considering both the fixed information including POD's names and stateful business logic, the strong binding of one POD and specific IP addresses needs to be implemented for static IP addresses.
+    For the static IP address requirement, there is a difference between stateless application and stateful application. Regarding stateless application like deployment, the POD's name will change when the POD restarts. Moreover, the business logic of the application itself is stateless, so static IP addresses are enabled only if all the POD replicas are fixed in a set of IP addresses; for stateful applications such as statefulset, considering both the fixed information including POD's names and stateful business logic, the strong binding of one POD and specific IP addresses needs to be implemented for static IP addresses.
 
     The "overlay network solution" mostly exposes the ingress and source addresses of services to the outside of the cluster with the help of NAT technology, and realizes the east-west communication through DNS, clusterIP and other technologies.
     In addition, although the IP block of IPAM fixes the IP to a node, it does not guarantee the application replicas to follow the scheduling.Therefore, there is no scope for the static IP address capability. Most of the mainstream CNIs in the community have not yet supported "static IP addressed", or support it in a rough way.
@@ -61,7 +61,7 @@ The disadvantage is that it poses network upgrading challenges for the cloud tra
 
 ### Underlay network solution
 
-This solution implements a shared host network for PODs, which means PODs can directly obtain IP addresses in the host network. Thus applications can directly use their own IP addresses for east-west and north-south communications.
+This solution implements a shared host network for PODs, which means PODs can directly obtain IP addresses in the host network. Thus, applications can directly use their own IP addresses for east-west and north-south communications.
 
 There are two typical scenarios for underlay network solutions：clusters deployed on a "legacy network" and clusters deployed on an IAAS environment, such as a public cloud. The following summarizes the IPAM characteristics of the "legacy network scenario":
 
@@ -132,7 +132,7 @@ If you want to start some Pods with Spiderpool in minutes, refer to [Quick start
 
 * Automatic implementation of static IP addresses and dynamic scalability of IP count
 
-    To realize static IP addresses, current open source projects hardcode IP addresses in the application's annotation, which leads to prone to operations accidents, manual operations of IP address conflicts as well as higher IP management costs caused by application scalability.
+    To realize static IP addresses, current open source projects hardcode IP addresses in the application's annotation, which is prone to operations accidents, manual operations of IP address conflicts as well as higher IP management costs caused by application scalability.
     Spiderpool provides CRD-based management to solve the above problems and minimize operation efforts.
 
     For stateless applications, the IP address range can be automatically fixed and IP resources can be dynamically scaled according to the number of application replicas. See [example](./docs/usage/????) for more details.

VERSION

@@ -1 +1 @@
-v0.4.0-rc3
+v0.4.0-rc4

charts/spiderpool/Chart.yaml

@@ -5,11 +5,11 @@ icon: https://raw.githubusercontent.com/spidernet-io/spiderpool/main/docs/images
 # application or library
 type: application
 # no need to modify this version , CI will auto update it with /VERSION
-version: 0.4.0-rc3
+version: 0.4.0-rc4
 # This field is informational, and has no impact on chart version calculations .
 # Leaving it unquoted can lead to parsing issues in some cases
 # no need to modify this version , CI will auto update it with /VERSION
-appVersion: "0.4.0-rc3"
+appVersion: "0.4.0-rc4"
 kubeVersion: ">= 1.16.0-0"
 description: ipam for kubernetes cni
 sources:

charts/spiderpool/crds/spiderpool.spidernet.io_spidersubnets.yaml

@@ -36,10 +36,6 @@ spec:
       jsonPath: .status.totalIPCount
       name: TOTAL-IP-COUNT
       type: integer
-    - description: default
-      jsonPath: .spec.default
-      name: DEFAULT
-      type: boolean
     name: v2beta1
     schema:
       openAPIV3Schema:
@@ -60,9 +56,6 @@ spec:
           spec:
             description: SubnetSpec defines the desired state of SpiderSubnet.
             properties:
-              default:
-                default: false
-                type: boolean
               excludeIPs:
                 items:
                   type: string

cmd/spiderpool-agent/cmd/crd_manager.go

@@ -36,13 +36,6 @@ func newCRDManager() (ctrl.Manager, error) {
 		return nil, err
 	}
 
-	if err := mgr.GetFieldIndexer().IndexField(agentContext.InnerCtx, &spiderpoolv2beta1.SpiderSubnet{}, "spec.default", func(raw client.Object) []string {
-		subnet := raw.(*spiderpoolv2beta1.SpiderSubnet)
-		return []string{strconv.FormatBool(*subnet.Spec.Default)}
-	}); err != nil {
-		return nil, err
-	}
-
 	if err := mgr.GetFieldIndexer().IndexField(agentContext.InnerCtx, &spiderpoolv2beta1.SpiderIPPool{}, "spec.default", func(raw client.Object) []string {
 		ipPool := raw.(*spiderpoolv2beta1.SpiderIPPool)
 		return []string{strconv.FormatBool(*ipPool.Spec.Default)}

cmd/spiderpool-controller/cmd/crd_manager.go

@@ -47,13 +47,6 @@ func newCRDManager() (ctrl.Manager, error) {
 		return nil, err
 	}
 
-	if err := mgr.GetFieldIndexer().IndexField(controllerContext.InnerCtx, &spiderpoolv2beta1.SpiderSubnet{}, "spec.default", func(raw client.Object) []string {
-		subnet := raw.(*spiderpoolv2beta1.SpiderSubnet)
-		return []string{strconv.FormatBool(*subnet.Spec.Default)}
-	}); err != nil {
-		return nil, err
-	}
-
 	if err := mgr.GetFieldIndexer().IndexField(controllerContext.InnerCtx, &spiderpoolv2beta1.SpiderIPPool{}, "spec.default", func(raw client.Object) []string {
 		ipPool := raw.(*spiderpoolv2beta1.SpiderIPPool)
 		return []string{strconv.FormatBool(*ipPool.Spec.Default)}

cmd/spiderpool-init/cmd/root.go

@@ -45,7 +45,6 @@ func Execute() {
 				IPVersion: pointer.Int64(constant.IPv4),
 				Subnet:    config.V4CIDR,
 				IPs:       config.V4IPRanges,
-				Default:   pointer.Bool(true),
 			},
 		}
 		if len(config.V4Gateway) != 0 {
@@ -68,7 +67,6 @@ func Execute() {
 				IPVersion: pointer.Int64(constant.IPv6),
 				Subnet:    config.V6CIDR,
 				IPs:       config.V6IPRanges,
-				Default:   pointer.Bool(true),
 			},
 		}
 		if len(config.V6Gateway) != 0 {

docs/README.md

@@ -1,4 +1,4 @@
-# Spiderpool
+# Overview
 
 ## Introduction
 

docs/concepts/arch.md

@@ -20,8 +20,10 @@ Spiderpool consists of following components:
 
 Spiderpool supports for the following CRDs:
 
-* ippool CRD. It is used to store the IP resource for a subnet. Refer to [ippool](./ippool.md) for detail.
+* SpiderSubnet CRD. It is used to represent a collection of IP addresses from which Spiderpool expects SpiderIPPool IPs to be assigned. Refer to [SpiderSubnet](./spidersubnet.md) for detail.
 
-* workloadendpoint CRD. It is used to store the IP assigned to a pod. Refer to [workloadendpoint](./workloadendpoint.md) for detail.
+* SpiderReservedIP CRD. It is used to represent a collection of IP addresses that Spiderpool expects not to be allocated. Refer to [SpiderReservedIP](./spiderreservedip.md) for detail.
 
-* reservedip CRD. It is used to set the reserved IP, which will not be assigned to a pod even if you have set it in the ippool. Refer to [reservedip](./reservedip.md) for detail.
+* SpiderIPPool CRD. It is used to represent a collection of IP addresses from which Spiderpool expects endpoint IPs to be assigned. Refer to [SpiderIPPool](./spiderippool.md) for detail.
+
+* SpiderEndpoint CRD. It is used to represent IP address allocation details for a specific endpoint object. Refer to [SpiderEndpoint](./spiderendpoint.md) for detail.