You can run your containers through a vulnerability scanner like Trivy and then patch with Copacetic. It will only fix the container image's OS vulnerabilities though, not the app code dependencies.
Otherwise one step simpler is you can just vulnerability scan the containers, look at the issues, then decide if you want to deploy them.
It's probably ultimately to do with whether you've set the correct port profiles on the switch and whether you've set the right IP addresses.
I started writing an explanation of VLANs, tags, trunk and client ports, and IP addresses but it quickly got long and I'm sure other people have done a much better job explaining elsewhere, so I suggest you do a bit of background reading or watching.
But, very briefly - you configure switch ports through profiles. The profiles say which VLANs are sent through that port.
If there is more than one VLAN being sent through a port the switch will send traffic tagged with the VLAN it belongs to, you need to configure the device connected to the port to understand those different VLAN tags, have more than one IP address, etc. These are usually called trunk or tagged ports on the switch. The switch expects to receive Ethernet traffic from the device already tagged with which VLAN it belongs to. If it receives a frame from the device without a VLAN tag, it will usually put it in the default VLAN, which is 1 on most switches.
If the device is just on one VLAN, the switch port facing it needs to be told it is a client or untagged port on that VLAN. Then it will remove the VLAN tag before it sends traffic so your device only sees standard Ethernet frames and it doesn't need to understand VLANs at all. When your device sends traffic, the switch will put the right VLAN tag on it before sending it onwards. If you don't tell the switch which VLAN the port belongs to, it will usually assume 1. You need to make sure your device has an IP in the right range for the VLAN it's in.