tokers opened a new issue #223: URL: https://github.com/apache/apisix-ingress-controller/issues/223
The current design about CRDs basically follows the configuration of [Apache APISIX](http://apisix.apache.org/), i.e. ApisixRoute for Route, ApisixService for Service and ApisixUpstream for Upstream. See [CRDs specification](https://github.com/apache/apisix-ingress-controller/blob/master/docs/CRD-specification.md) for details. The APISIX Service (distinguish from Kubernetes Service, so adding the APISIX prefix) is used for sharing plugins and upstreams, now it becomes more and more unnecessary since the upstream already can be reused by the `upstream_id`, and plugins can also be reused in the near future (by the `plugin_id`). Based on the current status, the `ApisixService` can be obsoleted. Just ApisixRoute and ApisixUpstream are required. For the sake of the service discovery mechanism in Kubernetes, ingress controller has to rely on the Kubernetes Service/Endpoints, and that's the source of the `nodes` in APISIX Upstream, other fields, like health check, retry, timeout and scheme, should be filled in another way, and here the ApisixUpstream CRD comes in. ApisixUpstream will be a decorator of Kubernetes Service. It's designed to have same name with its target Kubernetes Service. ```yaml apiVersion: v1 kind: Service metadata: name: httpbin spec: selector: app: httpbin ports: - name: http port: 80 targetPort: 8080 protocol: TCP --- apiVersion: apisix.apache.org/v2alpha1 kind: ApisixUpstream metadata: name: httpbin spec: loadbalancer: roundrobin timeout: 5s scheme: http ``` APISIX Upstream is at the level of Kubernetes Service port, so a Kubernetes Service might maps to multiple APISIX Upstreams, this is due to the design of APISIX Upstream is more like a group of logical similar endpoints, and all configurations are put in the Upstream level, not the endpoint/node level. When the Kubernetes Service httpbin is used in ApisixRoute or Ingress , the corresponding Upstream(s) will be created (lazily), an Upstream name will be generated by `{Namespace of Kubernetes Service}_{Name of Kubernetes Service}_{Kubernetes Service Port}`. Sometimes a Kubernetes Service might expose multiple ports and each of them needs different configurations, ApisixUpstream provides a field `portLevelSettings`, which allows to configure for individual port. ```yaml apiVersion: v1 kind: Service metadata: name: httpbin spec: selector: app: httpbin ports: - name: http port: 80 targetPort: 8080 protocol: TCP - name: https port: 443 targetPort: 8443 protocol: TCP --- apiVersion: apisix.apache.org/v2alpha1 kind: ApisixUpstream metadata: name: httpbin spec: loadbalancer: roundrobin timeout: 5s scheme: http portLevelSettings: - port: number: 443 scheme: https timeout: 10s ``` Configurations in the level of ports will inherit and override the same one in the ApisixUpstream level. As the above mentioned, Upstream(s) created only when the Kubernetes Service was referenced. That means when you create/update an ApisixUpstream resource, apisix-ingress-controller will look up the corresponding Upstreams from APISIX, and only if the Upstream exists, updating its configuration; it's similar when you delete an ApisixUpstream, existing Upstream(s) were not deleted but all the configurations on them were reset. APISIX Upstreams create/delete happens when ApisixRoute/Ingress create/delete. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
