-
Which controller is responsible for scheduling a pod on a node?
- Kubelet
- ReplicaSet
- kube-scheduler
Ans: 1. deployment -> replicaset -> kube-scheduler -> kubelet
-
Arrange in sequence all controllers that play a role in launching a pod via a deployment?
- deployment -> replicaset -> kube-scheduler -> kubelet
- Deployment -> kubelet
- Deployment -> replicaset -> pod -> scheduler
Ans: 1. deployment -> replicaset -> kube-scheduler -> kubelet
-
How does kuberentes API handles two concurrent writes to update a cluster object?
- Rejects both writes
- Accept first write, rejects second. Controller must retry / handle conflicts
- Queue the write operations - execute one after another
- Result of concurrent write is undeterministic
Ans: 2. Accept first write, rejects second. Controller must retry / handle conflicts
-
Which command will you use to proxy Kubernetes APIs on local machine?
Ans: kubectl proxy
-
How do you get the supported API Versions on a kubernetes cluster?
Ans: kubectl api-resources
-
How do you get supported API Resources on a kubernetes cluster?
Ans: kubectl api-resources
-
Find out the GVR for Deployment.
Ans: group: apps version: v1 resource: deployments
-
Find out GVK for Pods
Ans: group: - (comes in core/legacy api-group) version: v1 kind: pods
-
Find out GVR for CronJob
Ans: group: batch version: v1 resource: cronjobs
-
ServiceAccount is a non-namespaced resource - True / False
Ans: False.
-
Namespace is a ?
- namespaced resource
- non-namespaced resource Ans: 2. non-namespaced resource
-
Which of the following statements are true about GVK
- A Kind can be part of one and only one groupversion
- A Kind can be part of more than one groupversions simultaneously, but can only be retrieved as representation of a single groupversion for a cluster
- A Kind can be part of more than one groupversions simultaneously, and can be retrieved as representation of any of those groupversions for a cluster
Ans: 3. A Kind can be part of more than one groupversions simultaneously, and can be retrieved as representation of any of those groupversions for a cluster
-
In API Server response processing, which of the following is true?
- Mutating webhooks come before Validating webhooks
- Validating Admission Webhooks come before mutating webhooks
Ans: 1. Mutating webhooks come before Validating webhooks
-
API Server persists the state of various objects in etcd always
- True, API Server always uses etcd to store state
- False, it depends on the kubernetes distro, etcd may be replaced by other options
Ans: 2. False, it depends on the kubernetes distro, etcd may be replaced by other options
-
The client-go library should be imported in the project as
- github.com/kubernetes/client-go
- K8s.io/client-go
Ans: 2. K8s.io/client-go
-
Which method is used to parse kubeconfig file?
- Clientcmd.BuildConfigFromFlags
- Rest.InClusterConfig
Ans: 1. Clientcmd.BuildConfigFromFlags
-
The default wire format of client-go is
- JSON
- Protobuf
- XML
Ans: 1. JSON, 2. Protobuf
-
The TypeMeta struct contains which of the following fields (select all) :
- Kind
- APIVersion
- Name
- UID
Ans: 1. Kind, 2. APIVersion
-
The ObjectMeta contains resourceVersion - True / False
Ans: True
-
The clientset returned by kubernetes.NewForConfig(config) gives access to
- Only stable API groups and resources
- Only stable and beta versioned API groups and resources
- All API groups and resources
- All API Groups and resources defined in k8s.io/api, but not for custom resource definitions
Ans: 4. All API Groups and resources defined in k8s.io/api, but not for custom resource definitions
-
Identify the non-long-running requests from following :
- exec
- List
- Watch
- Port-forward
- Update
- Create
- Logs
Ans: 2. List, 5. Update, 6. Create, 7. Logs
-
Non-long-running requests are bounded by
- 30 sec
- 45 sec
- 60 sec
- 120 sec
Ans: 3. 60 sec
-
List four reasons why Informers are preferred over Watches? Ans: 1. if we use watch in custom controllers everytime we need access to kubernetes object/resource, it will overload traffic on Kube-Api-Server due to frequent polling. Informers use local cache to avoid frequent calls to Kube Api server.
2. Informers provide error handling by some in-built retry mechanism. 3. Single resource can be watched by multiple controllers. Here Shared Informer Factory is used so that the cache is shared among controllers. 4. With Informers We can register functions to listen to ADD, Update and Delete events.
-
The mapping of GVK to GVR is called :
- RESTMapping
- Scheme
Ans: 1. RESTMapping
-
By conventions, kinds are :
- Formatted in lowercase, and usually singular
- Formatted in CamelCase and usually singular
- Formatted in lowercase, and usually plural
- Formatted in CamelCase and usually plural
Ans: 2. Formatted in CamelCase and usually singular
-
By convention, resources are :
- Formatted in lowercase, and usually singular
- Formatted in CamelCase and usually singular
- Formatted in lowercase, and usually plural
- Formatted in CamelCase and usually plural
Ans: 3. Formatted in lowercase, and usually plural
-
Kinds map to ……… and resources map to …….
- Go types, REST Endpoints
- REST Endpoints, Go types
Ans: 1. Go types, REST Endpoints
-
Which of the following is not a Kind:
- Pod
- Deployment
- services
- Status
Ans: 4. Status
-
CRDs are kuberentes resources in
- apps/v1
- extensions/v1beta1
- apiextensions.k8s.io/v1beta1
Ans: 3. apiextensions.k8s.io/v1beta1
-
For a custom resource kind "step", what will be default listKind?
- steps
- listSteps
- stepList
Ans: 3. stepList
-
Select all subresources supported by Custom resources :
- logs
- status
- exec
- scale
Ans: 2. status, 4. scale
-
Define a custom resource YAML with following validations :
- Spec must contain image, owner and locale fields
- Locale must be one of EN, DE
- owner must start with "org.io/"
- image must contain the tag and it should not be "latest"
Ans:
-
How does the scale subresource identify the json path for replicas?
- It's always .spec.replicas
- It's defined in Scale kind from autoscaling/v1 API group
- Replica json path needs to be defined in CRD
Ans: 2. It's defined in Scale kind from autoscaling/v1 API group
-
Scale subresource can change
- only status & replicas of the resources
- only replicas of the resources
- status, lables and replicas of the resoureces
Ans: 1. only status & replicas of the resources
-
Identify a typed client from the following:
- client-go
- controller-runtime
Ans: 2. controller-runtime
-
For typed client, the processed types must be known at complie time
- true
- false
Ans: 1. true
-
Select valid constraints when using dynamic clients :
- GVKs must be known at complile time
- RESTMapper is not used, so developer needs to provide GVR
- It only uses unstructured.Unstructured go type
Ans: 2. RESTMapper is not used, so developer needs to provide GVR 3. It only uses unstructured.Unstructured go type
-
For a custom resource, "step" with group infracloud.io, and version v1beta1, the Go types are traditionally defined in
- types.go in pkg/apis/group/version
- types.go in pkg/apis/infracloud.io/v1beta1
Ans: 2. types.go in pkg/apis/infracloud.io/v1beta1
-
Which code-generators will you use for kubernetes controllers
- vendor/k8s.io/code-generator
- github.com/kubernetes/code-generator
Ans: 1. vendor/k8s.io/code-generator
-
Global tags are written into
- package's
doc.go
- package's
type.go
- kubeconfig file
Ans: 1. package's
doc.go
- package's
-
first-comment-block is
- directly above the type / package line
- separated from the type / package line by atleast one empty line
Ans: 1. directly above the type / package line
-
For content to show up in API HTML documentation
- It must be added to second-comment-block
- It must be added to first-comment-block
Ans: 2. It must be added to first-comment-block
-
+groupName
tag is- Optional, only added for information purpose
- Mandatory, defines the fully qualified group name
- Optional, only needed if Go parent package name doesn't match group name
Ans: 3. Optional, only needed if Go parent package name doesn't match group name
-
Tags are generally added to
- second comment block so that those can be added to API documentation
- first comment block so that those are added to API documentation
- second comment block so that those can be skipped from API documentation
Ans: 3. second comment block so that those can be skipped from API documentation
-
For
+genclient
tag, default is to- generate a namespaced client
- generate a non-namespaced client
- No default, it must be specified whether the resource is namespaced / non-namespaced
Ans: 1. generate a namespaced client
-
+genclient
must be added to type and List type of API Object- true
- false
Ans: 2. false
-
Let's say we don't want spec / status split for our CR. To achieve this
- We need to add
+genclient
tag which will by default not generate a updateStatus method - we need to add
+genclient:nostatus
so that the updateStatus method is not generated - we need to add
genclient: skipVerbs=status
tag
Ans: 2. we need to add
+genclient:nostatus
so that the updateStatus method is not generated - We need to add
-
Select all RBAC permissions that are needed for the custom API Server service account?
- get, list, watch namespaces
- get, list, watch pods
- get, list, watch validatingwebhookconfigurations
- get, list, watch mutatingwebhookconfigurations
- create pods
- delete pods
Ans: 1. get, list, watch namespaces 3. get, list, watch validatingwebhookconfigurations 4. get, list, watch mutatingwebhookconfigurations
-
CRDs support Protobuf and JSON
- True
- False
Ans: 2. False
-
List down advantages of Custom API Servers over CRDs
Ans:Custom API Servers : 1. Can use any storage medium. 2. Can provide protobuf support like all native Kubernetes resources do. 3. Can implement all operations like validation, admission, and conversion reducing latency. 4. Can implement graceful deletion. 5. highly customizable
-
What are some key reasons you would choose CRDs over custom API Servers?
Ans: 1. purely declarative. 2. dont need another api server. 3. overall less complex than witing custom api servers with golang.
-
How does
kube-aggregator
know which resources are served by a custom API Server?- It queries custom API Servers
- Resources served by custom API Servers are registered with kube-apiserver
- Using APIService objects which list the API Groups and Versions
Ans: 3. Using APIService objects which list the API Groups and Versions
-
The
service
in APIService object must serve port 443 and cannot use any other port- True
- False
Ans: 1. True
-
Let's say I have a group
citadel.infracloud.io
with three versions values as follows. What is the overall GroupPriority for the groupcitadel.infracloud.io
citadel.infracloud.io\v1 : GroupPriorityMinimum: 1000
citadel.infracloud.io\v1 : GroupPriorityMinimum: 900
citadel.infracloud.io\v1 : GroupPriorityMinimum: 1100
- 1000
- 900
- 1100
Ans: 3. 1100
-
Custom API Servers authorize requests by (choose multiple if valid) :
- Delegating to kube-apiserver via TokenAccessReviews
- Delegating to kube-apiserver via SubjectAccessReviews
- Through authorization chain in Custom API Server
- Requests are pre-authorized by kube-apiserver authorization module
- Authorization cache in Custom API Server
Ans: 2. Delegating to kube-apiserver via SubjectAccessReviews 3. Through authorization chain in Custom API Server 5. Authorization cache in Custom API Server
-
The API business logic is implemented :
- For each external version
- Only once for internal version
- Only for most recent external API Version
Ans: 3. Only for most recent external API Version
-
For an API Server serving single API Group with 2 versions (v1alpha1 & v1beta1) and 1 validating webhook, how many conversions are carried out between internal and external versions for a single create / update request?
- 4
- 6
- 2 (only for v1alpha1, v1beta1 is same as internal since its the latest version — so no conversion needed)
- 2 (only once from external to internal version and vice-versa. All API logic & storage is then in internal version )
Ans: 1. 4
-
For the example in above question, how many times
Defaulting
takes place for a create / update request?- 1
- 2
- 4
- 6
Ans: 2. 2
-
What are the differences between types.go for internal and external types? (Select All)
- JSON & protobuf tags are missing from external types.go
- JSON & protobuf tags are missing from internal types.go
- types.go for internal versions is in
pkg/apis/group-name/types.go
and for external versions inpkg/apis/group-name/version/types.go
- Latest API version is same as internal version
Ans: 2. JSON & protobuf tags are missing from internal types.go 3. types.go for internal versions is in
pkg/apis/group-name/types.go
and for external versions inpkg/apis/group-name/version/types.go
-
Modify the Pizza example API server in the Programming Kubernetes book for the following :
- Add a new version
v2alpha1
- In this version, add a new field
size
with optionsSmall
,Medium
,Large
- Add a validation to ensure the
size
value is one of the allowed values - Default the
size
toMedium
- Implement validating admission plugin to reject the request if another pizza of same size is already available in a given namespace
Ans: repo link: https://github.com/sandeshlmore/pizzaserver
- Add a new version
-
For a CRD
Pizza
, following versions are defined :v1
,v1alpha1
,v1beta1
,v2experimental
. For a requestkubectl get Pizza
which version will be returned?- v1beta1
- v2experimental
- v1
- v1alpha1
Ans: 3. v1
-
How do you specify the versions supported by a conversion webhook?
-
version is specified in the endpoint e.g.
/convert/v1beta1/pizza
,/convert/v1alpha1/pizza
etc -
Checked only in the
convert
function in the conversion webhook.if apiVersion != v1beta1.SchemeGroupVersion.String() { return nil, fmt.Errorf("cannot convert %s to %s", v1alpha1.SchemeGroupVersion, apiVersion) }
-
All versions of a CRD must be supported by a conversion webhook as only one such webhook can be specified
Ans: All versions of a CRD must be supported by a conversion webhook as only one such webhook can be specified
-
-
Custom Admission Webhooks can only be added for CRDs and not for native Kubernetes resources
- True
- False
Ans: 2. False
-
The order for mutating and validating webhooks is :
- Validating -> Mutating
- Mutating -> Validating
Ans: 2. Mutating -> Validating
-
Kubernetes API Server calls
- Mutating webhooks parallely, validating webhooks sequentially
- Mutating webhooks sequentially, validating webhooks sequentially
- Mutating webhooks sequentially, validating webhooks parallely
Ans: 3. Mutating webhooks sequentially, validating webhooks parallely