jefflill
commented
2 years ago Here's how this is landing:
-
[x] I've added the new ClusterDefinition.Registry.SearchRegistries property. This is a list may be set to the registry's DNS host names to [ "docker.io" ]. Setting this to NULL or an empty array disables default registry lookups.
-
[x] I also added the ClusterDefinition.Registry.Registries property so user can manage registry security, forwarding, blocking, etc.
-
[x] I had to remove the idempotent check in the NodeSshProxy.NodeInstallCriO() method because we'll need to re-run this during cluster setup, otherwise we'd never override what was configured for the node images.
-
[x] I added the KubeSetupProperty.Preparing property. This is a boolean that will be TRUE when preparing a cluster and FALSE when setting one up. NodeSshProxy.NodeInstallCriO() now does the full CRI-O installation and configuration when preparing a cluster and just regenerates the CRI-O config when setting up a cluster.
-
[x] We need to support secured container registries. We'll track this separately here: #1332
I'm starting to play around with the Bridge to Kubernetes Sample tutorial in a neonKUBE cluster and after applying the manifests, the pods aren't starting due to ImageInspectError.
After poking around a bit, I realized that the problem is that the pod container images are hosted on docker.io and these are referenced like azdspublic/bikesharing-reservationengine instead of docker.io/azdspublic/bikesharing-reservationengine. Other samples use Helm charts to deploy which means image repository references will be all over the place,
The problem here is that neonDESKTOP is intended for beginning Kubernetes users and many of them will go looking for tutorials about doing Kubernetes stuff on the web and it's very likely that many or most of these tutorials won't work out-of-the-box because they assume docker.io is the default registry and I assume that this will likely be the case for most other Kubernetes distributions because docker has been the default CRI for so long.
@marcusbooyah: I know you had configured CRI-O with default aliases several months ago and then we decided to drop that for some reason. I don't remember exactly why, but it may have been due to the chaos Docker caused when they start imposing rate limits a year ago.
I think we'll probably need to address this, we don't want many user's first experience with neonKUBE to be disappointing and then require them to modify Kubernetes manifests and Helm charts right before anything will work and before they have much of a clue about what those things even are.