Azure
[Feature] Allow change of proxy connectivity after deployment of AKSEE
Is your feature request related to a problem? Please describe. Yes, the request is directly linked to a AKSEE-based product delivery challenge as follows: We are working for a large customer who is building appliances of which an essential part is an industry PC (IPC). Today, core parts of the product run on the IPC as docker containers. In the very near future, these containers should be pods running in AKSEE. However, this is where we meet a challenge today: in the current production process the IPC is installed completely at the factory (e.g. usb stick iso): this includes the native windows apps but also the containers. In order to comply with our customers' processes, we would like to mimic this behavior with AKSEE. Hence, this would mean: (1) deploy AKSEE during install at the factory and (2) deploy workloads also at the factory then ship to customer. However, since connection details (PROXY) are different at the customer and at the production facility this approach fails today.
- NOTE1: of course, also the AKSEE ip range settings would be a problem here, but we would take the "risk" (inform customer up front) to set this to a fixed localnet range similar to what docker is doing with its default range 172.16.0.0/16).
- NOTE2: today the product cannot make use of remote orchestration and is using an alternative (offline) approach to update containers; while this will change in the long-term it means that we cannot simply pull images from arbitrary registries but must rely on offline loading of pods (this is relevant in the context of the described alternatives below)
Describe the solution you'd like We would like an extension of AKSEE Powershell or AKS-Edge AIDE functions to modify the proxy settings of AKSEE after deployment.
Describe alternatives you've considered
- We could deploy at the customer (and configure connectivity) but:
- it will prolong the installation process significantly (making it more expensive and error prone)
- require that during initial install (usb stick) the containers are "parked" somewhere and then only installed when AKSEE is ready (breaking a onestep solution into at least two steps); this is due to fact that we cannot allow registry downloads at this point and need to bring everything along (see above)
- make installation much more complex e.g. because certain components needed during setup at customer are pods which are only available after aksee is deployed
- Another option would be the manipulation of the config & env files directly in Mariner, but we would rather prefer to use official and esp. supported solutions
Additional context See above
the documentation from kk3s implies this is possible post installation https://docs.k3s.io/advanced#configuring-an-http-proxy "Of course, you can also configure the proxy by editing these files."
Any pws function should just modify these attributes
Hi @ivanthelad : thank you for your reply and the link. We are looking into it from our side, but as written above would prefer an official solution where we can be sure that it will also work in the future. Also: can you confirm that modifying the k3s env should also be sufficient for the arc kubernetes agent to connect through the proxy?
@scholz , AKS Edge Essentials does not currently support day 2 configuration changes, such as proxy changes. We have taken note of your request, and this feature is on our radar, although we do not currently have a timeline for when it will be available. Please let us know if you have any additional questions. Thank you for the feedback!
@SummerSmith , thank you for your response and for considering this. We’d really appreciate it if this item could be firmly scheduled soon, as we’re experiencing significant limitations, especially with larger corporate customers.
If I may ask a follow-up question: Do you think a (not-so-temporary) workaround using Arc Gateway could be an option? The proxy setting in Arc Gateway might allow for the exact kind of configuration we need. However, we’re uncertain whether it covers all cases for Arc-Kubernetes connectivity and whether private registries within Azure would be accessible through it for pulling container updates. Additionally, would it be valid to configure this as a proxy setting in the aksedge-conf.json so that K3s utilizes it as well?
It would be great if you could advise. Thanks so much!
(Just as an additional note: In discussions with the German MS support team, it seems proxy configuration might only be part of the challenge, as DNS or gateway settings may also require adjustments.)