I'm new to AWS and was asked as an exercise to deploy a Pod with admin permissions (binded to an admin service
account).
is such an "admin service account" already exists by default?
if no, how can you create such?
this is what I got, but don't know how to continue..
will appreciate any help.
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: pod_deployment
namespace: pod_deployment
spec:
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
-name: tcp
containerPort: 80
sreviceAccountName : admin (??)
Related
We have lunched .Net microservice on container and published it on EKS Cluster.
It's working fine on http.
We follow the link to deploy .Net microservice as deploy as a container.
https://dotnet.microsoft.com/en-us/learn/aspnet/microservice-tutorial/docker-file
We used below deploy.yaml
**---
apiVersion: apps/v1
kind: Deployment
metadata:
name: mymicroservice
spec:
replicas: 1
template:
metadata:
labels:
app: mymicroservice
spec:
containers:
- name: mymicroservice
image: [YOUR DOCKER ID]/mymicroservice:latest
ports:
- containerPort: 80
env:
- name: ASPNETCORE_URLS
value: http://*:80
selector:
matchLabels:
app: mymicroservice
apiVersion: v1
kind: Service
metadata:
name: mymicroservice
spec:
type: LoadBalancer
ports:
port: 80
selector:
app: mymicroservice**
This exposed our microservices behind classic load balancer. It's working fine on Http.
but we facing challenges on HTTPS. How can this be achieved? If we need to use Nginx Ingress Controller how that yaml we can tune according to our deployment.yaml
I am running Kubernetes cluster on my windows PC via Docker desktop. I am trying to create a very basic pod with a simple ingress configuration, but it doesn't seem to work. I thought the backend pod + service + ingress is a very basic setup, however I don't find a lot of help online. Please advise what I am doing wrong here.
My deployment.yaml file
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
service.yaml
apiVersion: v1
kind: Service
metadata:
name: test-cluster-ip
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 1234
targetPort: 80
ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: minimal-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
rules:
- http:
paths:
- path: /testpath
pathType: Exact
backend:
service:
name: test-cluster-ip
port:
number: 1234
This is what I see when I access localhost from the browser
Also, I would like to ask if it is uncommon to run Kubernetes on windows even for testing (especially with ingress). I don't seem to find a lot of examples in the internet.
I thought the backend pod + service + ingress is a very basic setup, however I don't find a lot of help online. Please advise what I am doing wrong here.
It is indeed a very basic setup. And your k8s deployment/service/ingress yaml files are correct.
First, check if you installed NGINX ingress controller. If not, run:
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.1/deploy/static/provider/cloud/deploy.yaml
After that, you will be able to reach the k8s cluster using the following URL:
http://kubernetes.docker.internal/
But deploying ingress like this:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: minimal-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
rules:
- http:
paths:
- path: /testpath
pathType: Exact
backend:
service:
name: test-cluster-ip
port:
number: 1234
you are configuring the ingress to rewrite /testpath to the /. And requesting url without /testpath will return 404 status code.
See more rewrite examples here.
So, if you use the following URL, you will get the Nginx webpage from k8s deployment.
http://kubernetes.docker.internal/testpath
I am trying to deploy a springboot application running on 8080 port. My target is to have https protocol for custom subdomain with google managed-certificates.
here are my yamls.
deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
namespace: my-namespace
spec:
replicas: 1
selector:
matchLabels:
app: my-deployment
namespace: my-namespace
template:
metadata:
labels:
app: my-deployment
namespace: my-namespace
spec:
containers:
- name: app
image: gcr.io/PROJECT_ID/IMAGE:TAG
imagePullPolicy: Always
ports:
- containerPort: 8080
resources:
requests:
memory: "256Mi"
ephemeral-storage: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
ephemeral-storage: "512Mi"
cpu: "250m"
2.service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: my-namespace
annotations:
cloud.google.com/backend-config: '{"default": "my-http-health-check"}'
spec:
selector:
app: my-deployment
namespace: my-namespace
type: NodePort
ports:
- port: 80
name: http
targetPort: http
protocol: TCP
ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
namespace: my-name-space
annotations:
kubernetes.io/ingress.global-static-ip-name: my-ip
networking.gke.io/managed-certificates: my-cert
kubernetes.io/ingress.class: "gce"
labels:
app: my-ingress
spec:
rules:
- host: my-domain.com
http:
paths:
- pathType: ImplementationSpecific
backend:
service:
name: my-service
port:
name: http
I followed various documentation, most of them could help to make http work but, couldn't make https work and ends with error ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Looks like there is issue with "Global forwarding rule". Ports shows 443-443. What is the correct way to terminate the HTTPS traffic at loadbalancer and route it to backend app with http?
From the information provided, I can see that the "ManagedCertificate" object is missing, you need to create a yaml file with the following structure:
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
name: my-cert
spec:
domains:
- <your-domain-name1>
- <your-domain-name2>
And then apply it with the command: kubectl apply -f file-name.yaml
Provisioning of the Google-managed certificate can take up to 60 minutes; you can check the status of the certificate using the following command: kubectl describe managedcertificate my-cert, wait for the status to be as "Active".
A few prerequisites you need to be aware, though:
You must own the domain name. The domain name must be no longer than
63 characters. You can use Google Domains or another registrar.
The cluster must have the HttpLoadBalancing add-on enabled.
Your "kubernetes.io/ingress.class" must be "gce".
You must apply Ingress and ManagedCertificate resources in the same
project and namespace.
Create a reserved (static) external IP address. Reserving a static IP
address guarantees that it remains yours, even if you delete the
Ingress. If you do not reserve an IP address, it might change,
requiring you to reconfigure your domain's DNS records.
Finally, you can take a look at the complete Google's guide on Creating an Ingress with a Google-managed certificate.
Background
I am using Docker for Windows v20.10.6 (with Kubernetes enabled).
I have created two simple, out-of-the-box .NET 5.0 applications:
1. Web API (reaching through HTTP, listening on port 7070)
2. Web App (MVC) that shows a parsed table from the Web API (listening on port 80)
A. ✔️ Created a connection between the applications using Docker Swarm Mode
Created a swarm using docker swarm init
Created an 'overlay' driver network named personal-overlay.
Created the Web API service using docker service create –-network personal-overlay --name api webapi
Created the Web App service using docker service create --name web –-network personal-overlay -p 30080:80 webapp
B. ✔️ Created a generic NGINX deployment and service
deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
tier: frontend
spec:
selector:
matchLabels:
app: myapp
replicas: 1
template:
metadata:
name: nginx
labels:
app: myapp
spec:
containers:
- name: nginx
image: nginx
service:
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: NodePort
ports:
- targetPort: 80
port: 80
nodePort: 30080
selector:
app: myapp
I could access the NGINX through http://localhost:30080 without an issue (using the web browser).
❌ The issue I'm currently facing
Tagged the images test/api and test/web
Created the same files using those Visual Studio images:
deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-deployment
labels:
tier: frontend
spec:
selector:
matchLabels:
app: myapp
replicas: 1
template:
metadata:
name: test-pod
labels:
app: myapp
spec:
containers:
- name: api
image: test/api
imagePullPolicy: Never
- name: web
image: test/web
imagePullPolicy: Never
service:
apiVersion: v1
kind: Service
metadata:
name: test-service
spec:
type: NodePort
ports:
- targetPort: 80
port: 80
nodePort: 30080
selector:
app: myapp
Yet, I can not access http://localhost:30080.
EDIT [1]:
I am trying to access it through the web browser, and I get an HTTP ERROR 500: "Failed to load resource: the server responded with a status of 500 (Internal Server Error)."
Whenever I am using curl -I http://localhost:30080 I get the following response:
HTTP/1.1 500 Internal Server Error
Date: Thu, 13 May 2021 08:20:25 GMT
Server: Kestrel
Content-Length: 0
EDIT [2]:
I even tried to scale it down into just this one pod (the web application).
pod:
apiVersion: v1
kind: Pod
metadata:
name: consumer-pod
labels:
name: consumer-pod
app: api-and-consumer
spec:
containers:
- name: consumer
image: test/web
imagePullPolicy: Never
ports:
- containerPort: 80
service:
apiVersion: v1
kind: Service
metadata:
name: consumer-external-svc
labels:
name: consumer-external-svc
app: api-and-consumer
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
nodePort: 30080
selector:
name: consumer-pod
app: api-and-consumer
Yet it does not work (with nor without the ports section at the pod YAML file).
These are the logs I get using the kubectl logs web-pod-<fullname> command (which says it is actually listening on port 80):
←[40m←[1m←[33mwarn←[39m←[22m←[49m: Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository[60]
Storing keys in a directory '/root/.aspnet/DataProtection-Keys' that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed.
←[40m←[1m←[33mwarn←[39m←[22m←[49m: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35]
No XML encryptor configured. Key {70ddc140-9846-4052-b869-8bcc5250d39e} may be persisted to storage in unencrypted form.
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.Hosting.Lifetime[0]
Now listening on: http://[::]:80
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.Hosting.Lifetime[0]
Hosting environment: Production
←[40m←[32minfo←[39m←[22m←[49m: Microsoft.Hosting.Lifetime[0]
Content root path: /app
I should also mention that using kubectl cluster-info dump I get the following line (for the service though, not the pod itself):
time="2021-05-13T10:56:35Z" level=error msg="Port 30080 for service web-external-svc is already opened by another service"
I created a service and use nodeport etc but couldn't access the service.
I created a web-service.yaml file with the following content and used kubectl to create the Service:
apiVersion: v1
kind: Service
metadata:
name: web-service
labels:
app: web-service
spec:
type: NodePort
ports:
- port: 80
protocol: TCP
selector:
app: webserver
and the webserver.yaml file with the following Deployment details
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: webserver
spec:
replicas: 3
template:
metadata:
labels:
run: webserver
spec:
containers:
- name: webserver
image: nginx:alpine
ports:
- containerPort: 80
In your deployment, label is run=webserver, but in your service, label is app=webserver. The service uses app=webserver as a Selector, through which it selects three pods that have the label "app" set to "webserver". In this case none of the pods has the label "app" so the deployment is not successfully exposed as a service. The label names and values in the deployment and service should match.