request help: 创建apisixupstream对象抛upstream is not referenced异常

[marchlhw]

Issue description

1. 我在使用apisix ingress controller的情况下，只创建apisixupstream对象，发现etcd中没有生产对应的upstream，如下：
   
   apisix ingress controller输出如下类似的日志：
   2022-02-13T15:16:29+08:00 warn apisix/upstream.go:70 upstream not found {"name": "apisix_httpbin_80", "url": "http://10.115.21.113:9180/apisix/admin/upstreams/f7a2533e", "cluster": "default"}
   2022-02-13T15:16:29+08:00 warn ingress/controller.go:653 upstream is not referenced {"cluster": "name=default; base_url=http://10.115.21.113:9180/apisix/admin", "upstream": "apisix_httpbin_80"}
   

2. 如果我删掉apisixupstream对象后，仅创建apisixroute对象，发现etcd中不仅创建对象了upstream，还创建了route，如下：
   
   
   

3. 述求：结合我们的实际使用场景，我只想在创建apisixupstream后，控制器调用apisix管理api在etcd中生成相应的upstream，并实时更新，其他的对象比如route、plugin、customer等统一通过dashbord创建，但是按照以上我实际测试出来的情况，满足不了我的诉求，不确定apisix ingress controller就是这么设计的，还是有问题

Environment

• your apisix-ingress-controller version (output of apisix-ingress-controller version --long):
  

• your Kubernetes cluster version (output of kubectl version):
  

• if you run apisix-ingress-controller in Bare-metal environment, also show your OS version (uname -a):
  

[tokers]

@marchlhw Unless the Kubernetes Service is referenced (used in ApisixRoute`), or the underlying APISIX Upstream won't be created, even if ApisixUpstream existing.

[marchlhw]

@marchlhw Unless the Kubernetes Service is referenced (used in ApisixRoute`), or the underlying APISIX Upstream won't be created, even if ApisixUpstream existing.

apisix-ingress-controller中apisixupstream的用途：仅仅是在原生kubernetes service需要丰富一些功能时使用，比如：健康检查，负载算法等，不需要这些功能就不用创建apisixupstrem。

apisix-ingress-controller中apisixupstream的逻辑有可能会改吗？创建apisixupstream crd并与kubernetes service关联也会创建upstream

[marchlhw]

apisix-ingress-controller中apisixupstream的逻辑有可能会调整吗？创建apisixupstream crd并与kubernetes service关联也会创建upstream

[tao12345666333]

This may be up for discussion.

[tao12345666333]

If you have time, you can join the meeting this Wednesday #614

[xuminwlt]

yes，we need too.
same to @marchlhw
Combined with our actual usage scenarios, I just want to create the apisix upstream, the controller calls the apisix management api to generate the corresponding upstream in etcd, and update it in real time. Other objects such as route, plugin, customer, etc. are uniformly created through dashbord, but according to The above situation I actually tested can not meet my demands

[tao12345666333]

I want to know, why not use declarative configuration directly in the Kubernetes environment, but rather a combination of declarative + dashboard? @xuminwlt @marchlhw

[xuminwlt]

We need a k8s-based service discovery function that can synchronize to the latest service pods information in real time. At present, only ingress has such a function, but the routing and consumer functions of the management side are currently carried out in the dashboard. Based on the current status , which is an optimal choice.

Our implementation process is:

1. The business applies for service access and generates the corresponding ingress apisixupstream.
2. After the business application is passed, you can go to the management platform to perform routing operations, and configure the corresponding Service, Route, and Consumer, which is actually the upstream in the Ingress synchronized to etcd.

This is our scene.

[tao12345666333]

got it.

[tao12345666333]

why: In most scenarios, we only need to define a ApisixRoute, and we don't need to bother to define ApisixUpstream. but, if we proxy a grpc service , we have to define ApisixUpstream like

apiVersion: apisix.apache.org/v1
kind: ApisixUpstream
metadata:
  name: yages
  namespace: ingress-apisix
spec:
  scheme: grpc

so suggest：proxy scheme should be in ApisixRoute not ApisixUpstream, that way we can do less work

copy from #871 @myselfghost

[jerrytaotz]

Yes！We need this feature too, eagerly

[xiangtianyu]

Our team have the same scenary, we may need this feature! Is there any schedule about this?

[xuminwlt]

In many cases, upstream is actually some kind of metadata. It is a system configured based on metadata, such as the publishing system. Routing is a dynamic configuration in which the control surface controls how traffic enters the corresponding upstream. It is more processed by the micro service traffic management system. If the two can be configured separately, it will bring great flexibility.

[tao12345666333]

@jerrytaotz @xiangtianyu @xuminwlt Thanks for your feedback. Based on discussions on multiple issues and community meetings, I added a triage/accepted label for this and added this feature to our roadmap.

I will write a proposal for the specific implementation plan.

[xuminwlt]

Great to me.

[jinjianming]

@marchlhw Unless the Kubernetes Service is referenced (used in ApisixRoute`), or the underlying APISIX Upstream won't be created, even if ApisixUpstream existing.

@tao12345666333 @tokers Hello to both of you.

I encountered a similar issue on #1855, but my 'ApisixRoute' is bound to the correct Kubernetes Service, which periodically prompts' warn Apisix/upstream. go: 69 upstream not found ', causing Apisix to process many useless requests;

My log does not contain 'upstream is not referenced', but there are many periodic warn apisix/upstream. go: 69 upstream not found that result in a large number of 404 requests from apisix every once in a while;

"This is causing me a lot of distress, and I hope you can provide me with some help. I am deeply grateful."

[tao12345666333]

These are two different issues. The core requirement in this issue has been resolved through #1019.

We can continue discussing your current issue in #1855. I will close this issue. Thanks