I created a deployment using kubernetes Deployment in openshift cluster. i expected it to create the service for all the container ports like openshift DeploymentConfig does.
but i did not find any service created by the kubernetes Deployment.
does kubernetes Deployment not create the service automatically like openshift DeploymentConfig does ?
My openshift version is 3.11
Both Deployment and DeploymentConfig does not create the Service component in OpenShift. These component are used for creation of Replication Control of the Pod.
Service has to be configured separately with the selector parameter to point to the specific Pods.
selector:
name: as in the deployment or in deploymentConfig.
This link would help you on the same.
https://docs.openshift.com/container-platform/3.3/dev_guide/deployments/how_deployments_work.html#creating-a-deployment-configuration
Deployment and service are different kubernetes objects. Deployment doesnt automatically create service object. you need to define service definition in a YAML targeting the ports from the pod definition inside deployment manifests. You need to deploy both deployment and service objects. you can deploy then separately or bundle them together in a single YAML and deploy.
Further details follow the link --> https://kubernetes.io/docs/concepts/services-networking/service/
Related
How do we define a Kubernetes Ingress for the backend kind Kubernetes Job?
Could not find specific reference from the documentation https://kubernetes.io/docs/concepts/services-networking/ingress/
A Job creates Pods as implementation.
An Ingress uses a Service to reach the correct Pods.
In order to make an Ingress for Pods created by a Job make sure that a Service exists with a selector that matches the labels of the Pods created by the Job.
Use that Service in the Ingress as target.
I already have 2 k8s deployments running without helm usage. Now, I have to add the following k8s object to it.
A NodePort Service
Toleration
NodeSelector
Host nginx as a load balancer service
I am trying to achieve it via helm. Can I use labels to connect helm charts with the existing deployment? Or, it is a mandate to use helm charts for the entire deployment?
Is there a way to kubernetes creates an ingress according to a just deployed service?
I've just created a k3d cluster and I''ve deployed my springboot service.
I've deployed a manifest with a DeploymentConfig and a Service.
I'd like this just created service is available out of kubernetes...
Any ideas?
How can one start a service or deployment just by using name of the service or deployment from kubernetes java sdk?
Suppose we have started and stopped the service or deployment once, so whether this can be achieved to just use the same name by which we have done the deployment or deployed the service.
For eg :
start a deployment by name nginx-deployment by using yaml file and then delete the deployment.
now try to start the same deployment just by using the name of previous deployment from kubernetes java sdk.
whether this can be achieved or not.
In kubernetes you can't stop a service, then to start it again (like in docker). Once a pod is killed, it will need to be re-created.
Now, if you delete a deployment, then you can re-create the same deployment, with the same name, with no problems.
If you are concerned about the state of the application, you can either use a StatefulSet or map the container content into an external volume. For example into the node.
In Kubernetes, it is possible to make a service running in cluster externally accessible by running kubectl expose deployment. Why deployment as opposed to service is beyond my simpleton's comprehension. That aside, I would like to also be able to undo this operation afterwards. Think of a scenario, where I need to get access to the service that normally is only accessible inside the cluster for debugging purposes and then to restore original situation.
Is there any way of doing this short of deleting the deployment and creating it afresh?
PS. Actually deleting service and deployment doesn't help. Re-creating service and deployment with the same name will result in service being exposed.
Assuming you have a deployment called hello-world, and do a kubectl expose as follows:
kubectl expose deployment hello-world --type=ClusterIP --name=my-service
this will create a service called my-service, which makes your deployment accessible for debugging, as you described.
To display information about the Service:
kubectl get services my-service
To delete this service when you are done debugging:
kubectl delete service my-service
Now your deployment is un-exposed.