"Supported resource types and properties" in https://cloud.google.com/deployment-manager/configuration/create-configuration-file has a "container.v1beta1.cluster", but the link is broken.
That link is fixed now: Google Container Engine API
The Cloud Deployment Manager uses the underlying APIs to do its work, so if the API exists, you should be able to use the Cloud Deployment Manager to do it. Quoting the docs:
Remember that Deployment Manager uses the underlying APIs of Google Cloud Platform services to manage resources in your deployment. If an API doesn't support a certain action, Deployment Manager cannot perform that action either. For example, Deployment Manager can only update an existing resource if there is an update method in the corresponding API.
So you should be able to create a cluster with the Cloud Deployment Manager.
Related
I tried to add a cluster into a cloud run using Anthos. In all the tutorials and forums am seeing the "Cloud Run(fully managed) and Cloud Run for Anthos" options. But when i tried I am not seeing these options under deployment.
I even tried to add the cluster from the option "Cloud Run for Anthos". It is throwing the below exception
"Cloud Run for Anthos is no longer available as a GKE add-on, and is now installed using Anthos fleets: https://cloud.google.com/anthos/run/docs/install"
The add-on itself is not getting enabled. Even though I enabled the "Cloud Run API" still have the same issue am facing.
In the trial version, Anthos would not get enabled. or what am I missing here?
please help me to resolve this issue. I have attached the screenshot for the reference.
Cloud run (fully managed) and cloud run for anthos are two diffrent products even if they have the same name ,
Cloud run for anthos is basically knative (older version) , however cloud run (fully managed) is a new technology developed by google, from what i understand the backend is not kubernetes,
If you want to use cloud run for anthos you should create your cluster from the anthos interface and not from the gke interface and enable cloud run for anthos,
i recommend using knative instead because you get to use all the new features (node selectors...) witch are not included in cloud run for anthos (no roadmap information / realse dates )
https://knative.dev/docs/install/
Currently we could create configmaps, deployment, pods, jobs, namespaces, ingress.
https://github.com/grafana/xk6-kubernetes
But I would like to deploy custom resources. Is it possible?
But I would like to deploy custom resources. Is it possible?
Creation of CR is possible. If definitions are maintained in yaml files for Custom resources, then CR can be applied or created using kubectl tool.
Usually Custom resources are associated with CRD's or API aggregators. Please refer kubernetes documentation for more details.
Adding custom resources
Kubernetes provides two ways to add custom resources to your cluster:
CRDs are simple and can be created without any programming.
API Aggregation requires programming, but allows more control over API behaviors like how data is stored and conversion between API versions.
This is not presently possible. Even when the recently introduced generic interface there are some issues regarding how Kubernetes API handles CRDs. Please refer to this open issue for tracking the progress of this requirement.
I followed the instructions on IoT Asset Tracking on a Hyperledger Blockchain . BUILD and DEPLOY finished successfully, but I can't find the composer-rest-server- app under Cloud Foundry Applications.
I can use the CF Blockchain services, enter the Monitor and open the Swagger UI. The question is, where can I find the application-specific APIs mentioned in the tutorial:
If everything deployed correctly, you can find the app in the IBM Cloud dashboard at https://console.bluemix.net. If you have many apps and services deployed, make sure to filter correctly or to be aware of paging.
If you suspect that something got wrong during build and deploy, go to the toolchain and check the logs. The toolchains can also be reached from the dashboard.
We have 2 namespaces as part of Azure SDK i.e. Microsoft.Azure.Management and Microsoft.WindowsAzure.Management.
1. How do we differentiate or which one to use when?
2. Is Microsoft.Azure.Management won't support all services?
3. I could able to create a classic storage account using Microsoft.WindowsAzure.Management and so is it only supports classic and not supports to create a storage account under a Resource Group?
Any light here would be appreciated?
How do we differentiate or which one to use when?
As far as I know, the Microsoft.Azure.Management is used to create the new arm azure resources.
The Microsoft.WindowsAzure.Management(you could see the last updated date is 2014/9/16) is used created the classic asm resources.
The difference between arm and asm, you could refer to this article.
I suggest you could choose Microsoft.Azure.Management to create new arm resources in azure. Like web app, VM and so on.
Because, multiple service now only support arm(e.g web app).
Is Microsoft.Azure.Management won't support all services?
Not all services is supported in Microsoft.Azure.Management, but it is still updating.
About the library supported service, you could refer to this.
I could able to create a classic storage account using Microsoft.WindowsAzure.Management and so is it only supports classic and not supports to create a storage account under a Resource Group?
Microsoft.WindowsAzure.Management doesn't support created the storage account under a resource group.
I want the ability for clients to create their own stateless services and be able to upload/publish it to join an existing cluster. Is this doable? I understand that I need to update the application manifests dynamically but not sure how or if this is possible programmatically without side effects of the service fabric runtime processes.
The workflow is to upload the code (zipped file maybe or whatever) via an API gateway.
The first thing to keep in mind is that you do not deploy individual services to a Service Fabric cluster. You deploy applications, which can contain one or more services.
So the key question to ask is whether you need the new code to be integrated with an existing application type or not. It sounds like what you're trying to do is just enable multiple clients to deploy independent applications on a shared Service Fabric cluster, in which case you would not be modifying existing application types, but deploying entirely new ones.
Thus, you would need your API gateway to dynamically generate application and service manifests, combine them with the client-provided code to create an application package, then copy, register, and create those applications in the cluster. As far as the Service Fabric runtime is concerned, this looks no different than if you had deployed an application type built and packaged in Visual Studio. Processes running existing applications are not impacted.